1 |
Hi, |
2 |
|
3 |
I'm still digesting this but I wanted to mention something that I have not seen mentioned in all the text I've read so far which is "64 bit". |
4 |
|
5 |
When I built my gcc this last time, I built gcc twice and the dependent libraries four times each. The process breaks down into this. |
6 |
|
7 |
For both passes, I do "out of tree" builds and build each library in 32 bit mode and again in 64 bit mode. I then rename the 32 bit shared object to e.g. libmpfr32.so.1, the 64 bit object to libmpfr64.so.1, and then create an archive called libmpfr.a. |
8 |
|
9 |
On the first pass, I specify where each library can be found. e.g. when I build mpfr, I told it that gmp is /down/this/path via the ./configure option. I built all libraries and gcc and "installed them". |
10 |
|
11 |
On the second pass (using the gcc and libs from the first pass), I set LIBPATH to /down/this/path:/lib but did not give any ./configure options to find the libraries. The build process finds and can use the libraries using LIBPATH. Again, I built all the libraries in both ABIs and finally built gcc. |
12 |
|
13 |
The final link of gcc it seems added in an absolute path for gettext but generally the objects in the libraries do not have any absolute paths except for the PATH[0] in the header. i.e. dump -H mpc32.so.2 for the "Import File Strings" is: |
14 |
|
15 |
***Import File Strings*** |
16 |
INDEX PATH BASE MEMBER |
17 |
0 /a/b/c:/lib |
18 |
1 libmpfr.a libmpfr32.so.1 |
19 |
2 libc.a shr.o |
20 |
3 libgmp.a libgmp32.so.10 |
21 |
|
22 |
So, I could move my libmpfr.a somewhere else, set my LIBPATH, and the load process would find it and use it. To me, this is nice. I can't say its a hugh advantage but one that would come in useful from time to time. |
23 |
|
24 |
I can now create 32 bit and 64 bit executables very easily. i.e. |
25 |
|
26 |
gcc -o x x.c |
27 |
|
28 |
creates a 32 bit executable while |
29 |
|
30 |
gcc -maix64 -o x x.c |
31 |
|
32 |
creates a 64 bit executable. The compile, link, and execute of either ABI doesn't require any gymnastics (LIBPATH is not set.) And, as an experiment, I moved my libmpfr.a library, pointed to it via LIBPATH, and could compile, link, and execute as well. So if things are in their normal position, no LIBPATH is needed. If they are moved elsewhere, setting LIBPATH allows them to be found and used. |
33 |
|
34 |
Again, to repeat, being able to move the libraries isn't my main objective. My main point here is that every library, under my blue sky dream, would be compiled with both ABIs so that users could build complicated applications in 64 bit mode with very little trouble. |
35 |
|
36 |
Let me get back to reading... |
37 |
|
38 |
Thank you, |
39 |
Perry |
40 |
|
41 |
On Dec 10, 2010, at 10:02 AM, Michael Haubenwallner wrote: |
42 |
|
43 |
> |
44 |
> |
45 |
> On 12/10/2010 04:34 PM, Perry Smith wrote: |
46 |
>> As I mentioned, I have done a lot with AIX and I'm really wanting this to work out. |
47 |
>> Please feel free to ping me about AIX questions and I'll try to help. |
48 |
> |
49 |
> There is one longstanding question I did not manage yet to finally find a good decision upon, |
50 |
> which gives a result being easy-understandable on both the filesystem and the shared objects, |
51 |
> as well as easy-useable for an ELF-originated package manager like portage & the ebuilds: |
52 |
> |
53 |
> How to implement the so-called "SONAME" feature with AIX shared objects (aka. shared libraries) |
54 |
> |
55 |
> Eventually you have some thoughts after reading these: |
56 |
> http://bugs.gentoo.org/show_bug.cgi?id=213277 |
57 |
> http://dev.gentoo.org/~haubi/aixrtl.txt |
58 |
> |
59 |
>> I don't know much about libtool and autoconf. |
60 |
> |
61 |
> Additionally, it is necessary to discuss this thing with libtool people. |
62 |
> I've tried this before already, but will have to do again, with more experience now. |
63 |
> |
64 |
> Thank you! |
65 |
> |
66 |
> /haubi/ |
67 |
> -- |
68 |
> Michael Haubenwallner |
69 |
> Gentoo on a different level |