More software development on the Ben: static linking works but shared linking fails--still!
Delbert Franz
ddf at sonic.net
Thu Dec 30 22:01:59 EST 2010
I have spent some more time (way too much) on sorting out why it is
not possible to create a shared library or executable on the Ben using
the native GCC and related tools. I reported this on 20 December so
this is an update to my E-mail on that date:
1. The first problem is the build uses sstrip, or super
strip, to remove unneeded information from shared libraries. The
libraries still work for loading with a shared executable but they
will not work for compiling a new one. Thus I changed the option to
do no stripping and rebuilt my images. I have also used strip and that
is okay and does reduce the sizes of the shared libraries. One can
still compile and link natively though.
2. That change, although, necessary, was not sufficient to solve the
problem. It took a while to find what caused link failure.
I finally sorted out how to turn on verbose reporting during
the link step; -Wl,--verbose, as an option to gcc gets lots of detail.
3 With verbose reporting, it became clear that the next obstacle is a
whole series of initialization and termination object files in an
invalid format for shared linking. These are located in :
/usr/lib/gcc/mipsel-openwrt-linux-uclibc/4.3.3
with names such as crt1.o, crtbegin.o, crtend.o, ....
These need to be recompiled with the -fpic option. These three
appeared sequentially as I tried to link. The first two I was able to
recompile on the Ben using -fpic and the linking got farther each
time. However, the compile of crtend.c failed with an inscrutable
message suggesting that some item of information was missing. At that
point I gave up trying to move forward.
Can someone with deeper knowledge of what is going on "under the hood"
or for the UK, "under the bonnet", outline how I can get the toolchain
and image compile to use -fpic when compiling these special routines?
That option is already used for all of the shared libraries-- that's a
requirement for such libraries:) Surely there is a way to do the same
for this collection of *.o files as well. Perhaps then a link of a
shared executable will go through. However, given my past experience,
there may yet be more things that need to be changed.
Also, can someone outline how to get the build to include the header
files and the static libraries on a package basis? These are needed to
do static linking, which works. The toolchain builds the static
libraries but does not include them in the package that gets installed
in the rootfs. Currently I just manually copy them over into a rootfs
that I construct on my host machine and then I copy it to the first
partition on my micro SD card. That works but is a bit cumbersome.
Using static linking I have been able to build all the demo programs from
the Ncurses Howto and also for the ncurses toolkit, CDK. The compiles
go through rather quickly, too:)
Thanks,
Delbert
More information about the discussion
mailing list