Gentoo Archives: gentoo-dev

From: Aron Griffis <agriffis@g.o>
To: gentoo-dev@g.o
Subject: [gentoo-dev] [ Re: 64-bit.eclass]
Date: Wed, 10 Dec 2003 19:28:36
Message-Id: 20031211012835.GB2313@time
1 ----- Forwarded message from Brad House <brad@×××××××××××××××××××.com> -----
3 From: Brad House <brad@×××××××××××××××××××.com>
4 Date: Wed, 10 Dec 2003 20:21:01 -0500
5 To: Daniel Robbins <drobbins@g.o>
6 Cc: Aron Griffis <agriffis@g.o>, alpha@g.o, amd64@g.o,
7 ia64@g.o
8 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031121
9 Subject: Re: 64-bit.eclass
11 Yeah, there are a couple of exceptions to what drobbins said here ...
12 It is said that you _should_not_ link a static library into a shared
13 object. The reason for this is most static libraries (.a's) are
14 not compiled with -fPIC, as they are mostly linked into executables,
15 and not shared objects.
16 Infact libtool inforces this on a few architectures/os's
17 (oddly enough one of those is ppc/MacOSX which it really doesn't
18 matter, because everything is PIC on ppc, so that's
19 counter-intuitive/productive, but don't get me started on libtool)
21 The reason I bring this up is I found one instance where
22 the ncurses static archive was linked into a shared object (yes,
23 odd, that's what I thought), none-the-less, the right thing to
24 do here is not patch ncurses itself. I can think of no conceivable
25 reason why ncurses should be linked into a shared object. None-the-less,
26 it is by this single application (which I could remember what it was,
27 it's on somewhere). It's that app that should really
28 be fixed to use the .so instead, but I didn't think of that at the
29 time.
31 This is definately an odd area, where a lot of apps aren't doing this
32 stuff right. And it is a real pain to edit the build system of all
33 these packages. I personally have marked quite a few with
34 append-flags just because I don't have the time to fix it 'right',
35 and the users would rather see it compile at all than to have it
36 not because a dev couldn't get to it. If it is mandated that
37 we must NOT use append-flags -fPIC, I will definately be inclined
38 to not fix the packages at all, as there are other things that
39 are a better use of my time at this point ... Not saying that
40 in the future it wouldn't be fixed though....just right now
41 I'm extremely busy.
43 -Brad
46 Daniel Robbins wrote:
47 >On Wed, 2003-12-10 at 17:03, Aron Griffis wrote:
48 >
49 >>Hi all,
50 >>
51 >>I committed 64-bit.eclass today which contains a single function:
52 >>64-bit. The point is to be able to recognize when you're building for a
53 >>64-bit architecture in a way where we can change the implementation as
54 >>needed.
55 >
56 >
57 >OK, there are a couple of problems with this approach:
58 >
59 >1) Adding -fPIC to the compile flags makes all the code relocatable,
60 >which is not the "right" solution for many packages (unless they are
61 >pure libraries)
62 >
63 >2) Lack of -fPIC is not a 64-bit issue in the first place, so there's no
64 >reason to have a "fix" associated with 64-bit.eclass. The problems tend
65 >to pop up on non-x86 systems, but it's really the fault of the Makefiles
66 >in these packages. The shipped Makefiles may (barely) work on x86, but
67 >they are not valid for non-x86 systems.
68 >
69 >The Makefiles happen to "work" on x86 because x86 supports non-PIC
70 >shared libraries, but it can only support them by doing text relocs.
71 >
72 >When a non-PIC shared library is used on x86, the dynamic loader is
73 >forced to create a private in-memory copy of the lib for every process
74 >using the library (after fixing up addresses in each copy so it can be
75 >used.) This means that if a package breaks during compile due to no
76 >-fPIC on alpha, ia64 and amd64, it also happens to be wasting a lot of
77 >memory on x86 (but nevertheless, the library does "work" on x86, even
78 >though it's technically broken.)
79 >
80 >The correct solution is to:
81 >
82 >1) find the specific sources where -fPIC is needed (and this should just
83 >be in cases of library code, not executables)
84 >
85 >2) make a patch to the Makefile/configure stuff to add -fPIC to these
86 >areas only.
87 >
88 >3) send patch upstream to fix their standard build scripts
89 >
90 >4) Use the patch on *all* architectures, including x86 (to avoid the
91 >text-reloc/memory wastage issue on x86)
92 >
93 >Then you have the right solution.
94 >
95 >Then, the problem is really fixed. Virtually all of the -fPIC issues can
96 >be tracked down to a bad Makefile. Again, it isn't a 64-bit or
97 >arch-specific quirk, but an issue of a broken Makefile, so the solution
98 >needs to be focused on fixing the Makefile for all arches.
99 >
100 >Regards,
101 >
102 >Daniel
105 ----- End forwarded message -----
107 --
108 Aron Griffis
109 Gentoo Linux Developer (alpha / ia64 / ruby / vim)
110 Key fingerprint = E3B6 8734 C2D6 B5E5 AE76 FB3A 26B1 C5E3 2010 4EB0


Subject Author
Re: [gentoo-dev] [ Re: 64-bit.eclass] Aron Griffis <agriffis@g.o>