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] |
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] |