[gentoo-dev] [[e-mail]: Re: 64-bit.eclass]

[Aron Griffis]

----- Forwarded message from Brad House <brad@×××××××××××××××××××.com> -----

From: Brad House <brad@×××××××××××××××××××.com>
Date: Wed, 10 Dec 2003 20:21:01 -0500
To: Daniel Robbins <drobbins@g.o>
Cc: Aron Griffis <agriffis@g.o>, alpha@g.o, amd64@g.o,
	ia64@g.o
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031121
Subject: Re: 64-bit.eclass

Yeah, 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