[Clfs-support] CLFS support

Andrew Bradford andrew at bradfordembedded.com
Tue Feb 11 13:05:15 PST 2014


On 02/11/2014 03:56 PM, Kevyn-Alexandre Paré wrote:

>> Possibly by using the '-X' switch to ldconfig, then the symlink won't be
>> removed.  But I believe this will mean patching gcc, but a quick check
>> means up to 212 times ldconfig can be called from gcc install and that
>> seems silly to patch all of them.  Or does it?
> 
> It seem silly and this problem should have been solved in other libc?!
> Looking at ulibc and glibc Makefile I don't see the direct same way as
> musl so I will need to run and make more test to see the diff...

Other libc use a separate ld and libc, so they don't have this problem.
 musl uses one file, libc.so, as both tasks and it determines which way
it's being used.

ldconfig is making a mostly sane assumption that symlinks within lib
dirs which don't go anywhere should be removed as they're likely left
over from old libs which are not installed anymore.  Usually this is not
a bad thing to do.

>> Would it be better to simply patch musl to have the symlink be relative
>> instead of absolute?  Although that's a better question for the musl ml
>> I think as I'm sure there's a good reason it's absolute...
> 
> Let's ask them!

The reason is that you may have a different syslibdir and libdir.  What
musl is doing is the right way for them, just annoying for us.

>>
>> Sorry I don't have any solution right now.  I thought this was working
>> well but apparently what ever my machine configuration was when I made
>> the edits to add musl meant that ldconfig wasn't doing what it does on
>> stock Debian Wheezy.  That's unfortunate.
> 
> Did you retest the script you have to see if this was happening also?
> There something to learn from that problem and we will found the best
> solution to fit our needs ;)

Yes, my script has the same problem.

-Andrew




More information about the Clfs-support mailing list