Running ldconfig
Michael Abbott
michael@araneidae.co.uk
Tue Nov 4 07:23:00 GMT 2008
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
More information about the crossgcc
mailing list