More software development on the Ben: static linking works but shared linking fails--still!

Delbert Franz ddf at
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 : 


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:)



More information about the discussion mailing list