[gentoo-dev] [brad@mainstreetsoftworks.com: Re: 64-bit.eclass]

[gentoo-dev] [brad@mainstreetsoftworks.com: Re: 64-bit.eclass]

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 4656 bytes --]

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

From: Brad House <brad@mainstreetsoftworks.com>
Date: Wed, 10 Dec 2003 20:21:01 -0500
To: Daniel Robbins <drobbins@gentoo.org>
Cc: Aron Griffis <agriffis@gentoo.org>, alpha@gentoo.org, amd64@gentoo.org,
	ia64@gentoo.org
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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [brad@mainstreetsoftworks.com: Re: 64-bit.eclass]

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

Brad,

Aron Griffis wrote:	[Wed Dec 10 2003, 08:28:35PM EST]
> 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.

Reading over Daniel's email, I don't think Daniel was saying that
"append-flags -fPIC" is completely disallowed.  I think his point was
that my "64-bit && append-flags -fPIC" is not the best way.  At the time
that I wrote my original email, I thought I was actually doing things
the best way, so Daniel's response was very helpful to clear up my
misconception (and prevent me from propogating it).

When fixing individual packages, there's always a trade-off between just
making things work, and taking the time to actually develop a correct
solution for the package in question.  In each case, it's going to come
down to how much time the developer has, and whether or not it's worth
pursuing the complete fix...

In the end, though, the best thing is to get it right and push the fix
upstream so that there's less future work for us to do. ;-)

Aron

-- 
Aron Griffis
Gentoo Linux Developer (alpha / ia64 / ruby / vim)
Key fingerprint = E3B6 8734 C2D6 B5E5 AE76  FB3A 26B1 C5E3 2010 4EB0


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]