Re: Running ldconfig

[Michael Abbott <michael at araneidae dot co dot uk>]

On Mon, 3 Nov 2008, Douglas Jerome wrote:
> At first I was a little puzzled at what you are trying to avoid. Now I 
> am also interested in a dynamically linked ldconfig. Please post your 
> progress towards that end.

Well, this is clearly an interesting question.  A couple of people have 
suggested that I build my ld.so.cache on first boot, which is a very 
sensible suggestion -- but thinking about it, my application will involve 
new software (and possibly libraries) being installed during the lifetime 
of the system, and not having ldconfig about would be annoying.

At the moment I'm in the throes of assembling my rootfs, and the ldconfig 
issue is more irritating than urgent: I begrudge it the room it consumes, 
but can afford it ... for the moment.  Somebody's threatening to cram 64M
of ADC linearisation data onto my 32MB flash (hahaha, but with compression 
it might fit) at which point the rules of the game would have to change, 
but for the moment I've got oodles of room.

Statically linking ldconfig is a cute idea, but it's rapidly slipping down 
the pile of jobs -- I've not even tried to build glibc in isolation yet 
(just used crosstool-ng).  I can see ldconfig mentioned in 
glibc-2.7/elf/Makefile, but the only relevant mention seems to be the 
following:


ifeq (yes,$(use-ldconfig))
ifeq (yes,$(build-shared))
others-static   += ldconfig
others          += ldconfig
install-rootsbin += ldconfig

ldconfig-modules := cache readlib xmalloc xstrdup chroot_canon
extra-objs      += $(ldconfig-modules:=.o)

# To find xmalloc.c and xstrdup.c
vpath %.c ../locale/programs

endif
endif


I guess it's adding ldconfig to the others-static list that makes it 
statically linked?  Maybe, but to be honest, I don't really see what's 
going on here, and I think I need to do some more urgent stuff for a bit!

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