This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mklibgcc fallout


David Edelsohn <dje@watson.ibm.com> writes:

>>>>>> Zack Weinberg writes:
>
> Zack> Y'all sort out what should be going on and I'll make it happen, if
> Zack> y'all don't beat me to it.
>
> 	The original semantics should be restored: all libgcc_s_* shared
> objects built in the main gcc build directory, not multilib
> subdirectories, and all libgcc_s_* shared objects installed in the lib
> directory, not multilib subdirectories.

It's not that simple.

A powerpc64-linux build tree from October contains the following files
named libgcc_s*so* which are of principal relevance


libgcc_s.so.1
32/libgcc_s.so.1
32/nof/libgcc_s_nof.so.1
libgcc_s.so -> libgcc_s.so.1
libgcc_s_32.so -> 32/libgcc_s.so.1
libgcc_s_32_nof.so -> 32/nof/libgcc_s_nof.so.1

You can see that this doesn't correspond exactly to what either you or
Alan has been saying.  The actual shared libraries are in the multilib
directories and all have the same basename, the files with suffixed
names are all together in the toplevel but they're symlinks.

There are also several other files which are a consequence of the
bootstrap process:

libgcc_s.so.1.stage1
libgcc_s.so.1.stage2
32/libgcc_s.so.1.stage2
32/nof/libgcc_s_nof.so.1.stage2
stage1/32/libgcc_s.so.1
stage1/32/nof/libgcc_s_nof.so.1
stage1/libgcc_s.so
stage2/32/libgcc_s.so.1
stage2/32/nof/libgcc_s_nof.so.1
stage2/libgcc_s.so

I can say with some confidence that the .stageN suffixed variants
should not exist, but not much else.  I don't have any confidence that
any of these layouts is right: not what you say, not what Alan says,
not the way it was in October.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]