This is the mail archive of the 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 <> 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
32/nof/ -> -> 32/ -> 32/nof/

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:

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.


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