On Fri, Jun 22, 2012 at 08:31:56PM +0200, Marc Espie wrote:
> On Thu, Jun 21, 2012 at 09:15:59AM +0200, Marc Espie wrote:
> > On Wed, Jun 20, 2012 at 06:47:03PM -0400, Brad Smith wrote:
> > >
> > > Please specify the exact ports you're attemtping to fix so that others
> > > can take a look and see
On Thu, Jun 21, 2012 at 09:15:59AM +0200, Marc Espie wrote:
> On Wed, Jun 20, 2012 at 06:47:03PM -0400, Brad Smith wrote:
> >
> > Please specify the exact ports you're attemtping to fix so that others
> > can take a look and see if there is the possibility of doing things in
> > a different / bett
This diff is totally broke. He never even tested it. Stay away
from it.
> So, here's the same diff with shlib glue.
>
> If you think that's slightly insane, blame bsd.lib.mk !
>
> Note: for now, there's only arch/libamd64.
> I don't feel qualified to comment/test/do the other arches if need be
On Thu, Jun 21, 2012 at 9:15 AM, Marc Espie wrote:
> On Wed, Jun 20, 2012 at 06:47:03PM -0400, Brad Smith wrote:
>>
>> Please specify the exact ports you're attemtping to fix so that others
>> can take a look and see if there is the possibility of doing things in
>> a different / better manner.
>
On Wed, Jun 20, 2012 at 06:47:03PM -0400, Brad Smith wrote:
>
> Please specify the exact ports you're attemtping to fix so that others
> can take a look and see if there is the possibility of doing things in
> a different / better manner.
security/pcsc-lite and sysutils/freeipmi
Note that you ne
> > > Wait a moment? libaamd64? What is this crap?
> > >
> > > Anything that links that into a shared library deserves not to run on
> > > OpenBSD!
> >
> > Go dive into the ports tree sometimes.
> >
> > You can either spend your life fixing one single port to be perfect, or
> > you can accept
On Thu, Jun 21, 2012 at 12:33:43AM +0200, Marc Espie wrote:
> On Wed, Jun 20, 2012 at 11:27:34PM +0200, Mark Kettenis wrote:
> > > Date: Tue, 19 Jun 2012 17:02:31 +0200
> > > From: Marc Espie
> > >
> > > On Tue, Jun 19, 2012 at 08:45:18AM -0600, Theo de Raadt wrote:
> > > > Oh whoops, I ok'd the
On Wed, Jun 20, 2012 at 11:27:34PM +0200, Mark Kettenis wrote:
> > Date: Tue, 19 Jun 2012 17:02:31 +0200
> > From: Marc Espie
> >
> > On Tue, Jun 19, 2012 at 08:45:18AM -0600, Theo de Raadt wrote:
> > > Oh whoops, I ok'd the previous!
> > >
> > > Come on Marc, you know better. That won't work o
> Date: Tue, 19 Jun 2012 17:02:31 +0200
> From: Marc Espie
>
> On Tue, Jun 19, 2012 at 08:45:18AM -0600, Theo de Raadt wrote:
> > Oh whoops, I ok'd the previous!
> >
> > Come on Marc, you know better. That won't work on the vax, which
> > has no PIC.
>
> LOL. I'm using PICFLAG, I'm hoping
> Date: Tue, 19 Jun 2012 17:02:31 +0200
> From: Marc Espie
>
> On Tue, Jun 19, 2012 at 08:45:18AM -0600, Theo de Raadt wrote:
> > Oh whoops, I ok'd the previous!
> >
> > Come on Marc, you know better. That won't work on the vax, which
> > has no PIC.
>
> LOL. I'm using PICFLAG, I'm hoping
> > Come on Marc, you know better. That won't work on the vax, which
> > has no PIC.
>
> LOL. I'm using PICFLAG, I'm hoping the vax has a define there.
*MEEP* Same player shoot again.
> Especially the second lib, what was its name, oh right,
> lib/arch/amd64.
And you mentioned libl initial
So, here's the same diff with shlib glue.
If you think that's slightly insane, blame bsd.lib.mk !
Note: for now, there's only arch/libamd64.
I don't feel qualified to comment/test/do the other arches if need be.
Index: libl/Makefile
==
On Tue, Jun 19, 2012 at 08:45:18AM -0600, Theo de Raadt wrote:
> Oh whoops, I ok'd the previous!
>
> Come on Marc, you know better. That won't work on the vax, which
> has no PIC.
LOL. I'm using PICFLAG, I'm hoping the vax has a define there.
I don't expect the corresponding software to wor
Oh whoops, I ok'd the previous!
Come on Marc, you know better. That won't work on the vax, which
has no PIC.
As Mark said, it has to be done properly.
> > Some ports want to aggregate these into shared objects...
> > this tends to fail.
> >
> > Any negative side-effect ?
>
> I think this is
> Some ports want to aggregate these into shared objects...
> this tends to fail.
>
> Any negative side-effect ?
I think this is a really bad idea. You're going to end up with multiple
copies of the code and you'll
never be quite sure what copy ends up being used. Especially dangerous
for dlo
I suppose if people want screw themselves using multiple lex
and run into trouble, it isn't our fault.
Note that netbsd libc has yacc in it and oh boy, they've had a
rough road there.
Some ports want to aggregate these into shared objects...
this tends to fail.
Any negative side-effect ?
Index: libl/Makefile
===
RCS file: /cvs/src/lib/libl/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- libl/Make
17 matches
Mail list logo
