----- Forwarded message from Brad House <[EMAIL PROTECTED]> -----
From: Brad House <[EMAIL PROTECTED]>
Date: Wed, 10 Dec 2003 20:21:01 -0500
To: Daniel Robbins <[EMAIL PROTECTED]>
Cc: Aron Griffis <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031121
Subject: Re: 64-bit.eclassYeah, there are a couple of exceptions to what drobbins said here ... It is said that you _should_not_ link a static library into a shared object. The reason for this is most static libraries (.a's) are not compiled with -fPIC, as they are mostly linked into executables, and not shared objects. Infact libtool inforces this on a few architectures/os's (oddly enough one of those is ppc/MacOSX which it really doesn't matter, because everything is PIC on ppc, so that's counter-intuitive/productive, but don't get me started on libtool) The reason I bring this up is I found one instance where the ncurses static archive was linked into a shared object (yes, odd, that's what I thought), none-the-less, the right thing to do here is not patch ncurses itself. I can think of no conceivable reason why ncurses should be linked into a shared object. None-the-less, it is by this single application (which I could remember what it was, it's on bugs.gentoo.org somewhere). It's that app that should really be fixed to use the .so instead, but I didn't think of that at the time. This is definately an odd area, where a lot of apps aren't doing this stuff right. And it is a real pain to edit the build system of all these packages. I personally have marked quite a few with append-flags just because I don't have the time to fix it 'right', and the users would rather see it compile at all than to have it not because a dev couldn't get to it. If it is mandated that we must NOT use append-flags -fPIC, I will definately be inclined to not fix the packages at all, as there are other things that are a better use of my time at this point ... Not saying that in the future it wouldn't be fixed though....just right now I'm extremely busy. -Brad Daniel Robbins wrote: >On Wed, 2003-12-10 at 17:03, Aron Griffis wrote: > >>Hi all, >> >>I committed 64-bit.eclass today which contains a single function: >>64-bit. The point is to be able to recognize when you're building for a >>64-bit architecture in a way where we can change the implementation as >>needed. > > >OK, there are a couple of problems with this approach: > >1) Adding -fPIC to the compile flags makes all the code relocatable, >which is not the "right" solution for many packages (unless they are >pure libraries) > >2) Lack of -fPIC is not a 64-bit issue in the first place, so there's no >reason to have a "fix" associated with 64-bit.eclass. The problems tend >to pop up on non-x86 systems, but it's really the fault of the Makefiles >in these packages. The shipped Makefiles may (barely) work on x86, but >they are not valid for non-x86 systems. > >The Makefiles happen to "work" on x86 because x86 supports non-PIC >shared libraries, but it can only support them by doing text relocs. > >When a non-PIC shared library is used on x86, the dynamic loader is >forced to create a private in-memory copy of the lib for every process >using the library (after fixing up addresses in each copy so it can be >used.) This means that if a package breaks during compile due to no >-fPIC on alpha, ia64 and amd64, it also happens to be wasting a lot of >memory on x86 (but nevertheless, the library does "work" on x86, even >though it's technically broken.) > >The correct solution is to: > >1) find the specific sources where -fPIC is needed (and this should just >be in cases of library code, not executables) > >2) make a patch to the Makefile/configure stuff to add -fPIC to these >areas only. > >3) send patch upstream to fix their standard build scripts > >4) Use the patch on *all* architectures, including x86 (to avoid the >text-reloc/memory wastage issue on x86) > >Then you have the right solution. > >Then, the problem is really fixed. Virtually all of the -fPIC issues can >be tracked down to a bad Makefile. Again, it isn't a 64-bit or >arch-specific quirk, but an issue of a broken Makefile, so the solution >needs to be focused on fixing the Makefile for all arches. > >Regards, > >Daniel ----- End forwarded message ----- -- Aron Griffis Gentoo Linux Developer (alpha / ia64 / ruby / vim) Key fingerprint = E3B6 8734 C2D6 B5E5 AE76 FB3A 26B1 C5E3 2010 4EB0
pgp00000.pgp
Description: PGP signature
