This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


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

Running ldconfig


I have an interesting dilemma with ldconfig.  On my tiny embedded box it 
is a bloated monster -- being statically linked doesn't help -- and I'm 
reluctant to give it house room.

I seem to have several choices, and I was wondering what experience others 
have had.  If I'm too off topic, please point me somewhere!

A little experimentation tells me that ldconfig merely optimises the 
startup of programs, so there seems to me to be no compelling reason for 
it to be statically built.  This presents one option: rebuild ldconfig to 
be dynamically linked.

A little further research with strace tells me that without ld.so.cache 
glibc does an awful lot of pointless hunting through the directory 
hierarchy to find its libraries, so leaving it out altogether seems a bit 
painful.  I guess some timing tests would be in order.

However, this being an embedded system and all, the obvious alternative 
seems to be to run ldconfig during the system build process.  
Unfortunately ldconfig doesn't do cross-system cache generation, and the 
idea of running up a qemu emulation just to run my ldconfig strikes me as 
rather overkill.

So: any sensible thoughts on this?  I'm tempted to try building a 
dynamically linked ldconfig...

--
For unsubscribe information see http://sourceware.org/lists.html#faq


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