Date: Tue, 7 Mar 2006 19:56:24 +0100 From: Roman Neuhauser <neuhauser@sigpipe.cz> To: Kris Kennaway <kris@obsecurity.org> Cc: pfgshield-freebsd@yahoo.com, freebsd-ports@FreeBSD.org Subject: Re: amd64 and -fPIC Message-ID: <20060307185624.GE73973@isis.sigpipe.cz> In-Reply-To: <20060307184210.GA33347@xor.obsecurity.org> References: <20060220041815.3229.qmail@web32907.mail.mud.yahoo.com> <20060220043813.GA82552@xor.obsecurity.org> <20060307183756.GD73973@isis.sigpipe.cz> <20060307184210.GA33347@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
# kris@obsecurity.org / 2006-03-07 13:42:10 -0500:
> On Tue, Mar 07, 2006 at 07:37:56PM +0100, Roman Neuhauser wrote:
> > # kris@obsecurity.org / 2006-02-19 23:38:13 -0500:
> > > On Mon, Feb 20, 2006 at 05:18:15AM +0100, pfgshield-freebsd@yahoo.com wrote:
> > > > Hi;
> > > >
> > > > amd64 has a rather nasty issue: in order to mix shared and static libraries
> > > > everything has to be built with -fPIC. Most ports are either static or dynamic
> > > > so it's usually not a problem, but I'm stating to find problems in the math
> > > > section: packages like arpack and glpk are only built static and without -fPIC.
> > > > And lately we are only building the dynamic version of ATLAS so packages that
> > > > use many math libraries will have problems on amd64.
> > > >
> > > > Someone would say the easy way out of this would be to add -fPIC to everything
> > > > by default, which works, but has some performance issues. If someone has a
> > > > better solution I would like to hear it (please!) but if not I would like to
> > > > suggest instead a general guideline:
> > > >
> > > > If the package includes a library that might be used frequently and doesn't
> > > > include a shared version please add -fPIC to the amd64 version of the port, for
> > > > example for math/arpack (and feel free to commit this):
> > >
> > > The best solution is to make the port also build a shared version;
> > > it's usually not that difficult to modify the makefile. That way you
> > > don't have to add nasty hacks.
> >
> > That doesn't solve the problem, which is: the static library is
> > almost useless, and users might actually want or need to use the
> > static library.
>
> Why do you say it's useless? The point of a static library is for
> static linking, and this works fine on amd64 or any other
> architecture.
I say so because I installed the library (using the port) to use it
in a shared library. The link failed with relocation errors. As far
as I'm concerned (on amd64, that is), the port is dead weight.
> > net/libpcap only installs lib/libpcap.so if you install into /usr,
> > probably because all the dependent ports would need to be taught
> > to look in /usr/local/lib first.
>
> I don't know what you're saying here.
/usr/lib is walked first, /usr/lib/libpcap.so.N will mask
/usr/local/lib/libpcap.so.M
> > misc/ossp-uuid's ${PREFIX}/lib/libuuid.a (it configures with
> > --disable-shared) cannot be used in shared libraries on amd64
> > because the port doesn't use -fPIC on this platform.
>
> The bug is presumably the --disable-shared.
I'd prefer to link in the .a even if there was a .so.
> > Ports that install static libraries *need* to use -fPIC on amd64.
>
> No, they need to also install shared libraries.
Ok, to help me understand your view:
Do you agree that it's a fact that static libraries installed
without -fPIC can be used to create shared libraries on eg. i386?
Do you agree that it's a fact that static libraries installed
without -fPIC *cannot* be used to create shared libraries on eg.
amd64?
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060307185624.GE73973>