> Date: Tue, 19 Jun 2012 17:02:31 +0200
> From: Marc Espie <es...@nerim.net>
> 
> 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.
> 
> LOOOOOL. I'm using PICFLAG, I'm hoping the vax has a define there.
> 
> I don't expect the corresponding software to work on the vax.
> Especially the second lib, what was its name, oh right,
> lib/arch/amd64.
> 
> > 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 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 dlopen()'ed stuff.
> > > 
> > > Turn it into a proper shared library instead.
> 
> Frankly, I don't expect those to turn up in triplicates. What I see here
> is just an extra layer of build goo that will create a library that is just
> part of a software that will most probably never include a second "same thing"
> anywhere.
> 
> So, turning that into a shared library is really a non-issue. It's just build
> goo.
> 
> I was really more thinking among the line: does compiling this as ${PICFLAG} 
> code has issues on any machine ? the only reason it matters is because 
> ld complains about relocations on amd64 if some code is pic and non-pic.
> ... and libtool (yeah right) would compile it as a real library on vax, so
> the non-pic flag is not an issue there.
> 
> Alternately, I can just keep it broken, and wait until someone fixes the
> affected ports while going insane (yeah, this is the kind of fucked-up
> build infrastructure we're talking about, see my latest commit to
> graphics/dcmtk, and the fact that libtool --version will say
> libtool (not (GNU libtool) 1.26
> just so that some fucked-up configure script won't say "hey, that's libtol.
> Oh that's not GNU libtool, so I'll just create a broken makefile"...
> 
> So, hey, doing a shared library is totally equivalent to me.
> I don't give a fuck as long as things work (it compiles, let's ship it, as
> kili would say...)
> 
> You guys seem to have an actual opinion about it, just
> tell me, the Makefile/shlib_version goo is equally trivial to write.

Yes, I have a clear preference for turning this into a shared library.

Reply via email to