Bug 5347

I have created an SDK using the command:
#  bitbake core-image-minimal -c populate_sdk

Installed the cross toolchain for x86:
# sh poky-eglibc-x86_64-core-image-minimal-i586-toolchain-1.5.sh 
#  source /opt/poky/1.5/environment-setup-i586-poky-linux

Tried to use the toolchain to build a static binary:
# cat test-static.c 

#include <stdio.h>
int main()
{
 printf("Static \n");
 return 0;
}

#cat Makefile
all:
        ${CC} test-static.c -static -o test

# make
i586-poky-linux-gcc  -m32 -march=i586 --sysroot=/opt/poky/1.5/sysroots/i586-poky-linux test.c -static -o test
/opt/poky/1.5/sysroots/x86_64-pokysdk-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.8.1/ld: cannot find -lc
collect2: error: ld returned 1 exit status
make: *** [all] Error 1

IMAGE_INSTALL_append = " eglibc-staticdev"

resolves this problem. Thanks to RP.

However, most of the cross-toolchains support "static" linking as a default behaviour. Can we follow the same path?

Would documentation of this issue be sufficient? Depending on the use case most development environements will be using dynamic linking. I can see in the smaller footprints static linking might be useful, but that might be limited cases, we don't want to add the overhead of the static libraries to all the dev images (yet get quite large).

(In reply to comment #3)
> Would documentation of this issue be sufficient? 
I do agree.

> Depending on the use case
> most development environements will be using dynamic linking. I can see in
> the smaller footprints static linking might be useful, but that might be
> limited cases, we don't want to add the overhead of the static libraries to
> all the dev images (yet get quite large).

Yes. Not everyone needs static linking.

Ideally, can we think of adding the minimum set of static libraries (libc, libc++) to the SDK ? Additional storage required for the static libraries are listed below (for arm):
# du -h *.a
116K    libanl.a
16K     libBrokenLocale.a
4.0K    libbsd-compat.a
17M     libc.a
72K     libc_nonshared.a
160K    libcrypt.a
36K     libdl.a
4.0K    libg.a
4.0K    libieee.a
2.3M    libm.a
12K     libmcheck.a
844K    libnsl.a
1.7M    libpthread.a
4.0K    libpthread_nonshared.a
444K    libresolv.a
228K    librpcsvc.a
296K    librt.a
9.7M    libstdc++.a
784K    libsupc++.a
36K     libutil.a

which is around 40M

Created attachment 1571 [details]
Documentation fix

Added a Note about this in the adt manual.

Hi, 

I took your patch and hand-applied it.  I did some technical writing on it so it is not verbatim.  You can examine the note here: http://www.yoctoproject.org/docs/1.6/adt-manual/adt-manual.html#optionally-building-a-toolchain-installer.

I flipped the "Documentation change" field to "Done".  Let me know if the note works.

Here is the commit URL: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/commit/?id=91409d77d68e55f4089cab3e7f48dd385dddff2e

Thanks, 
Scott

Hi,

(In reply to comment #6)
> Hi, 
> 
> I took your patch and hand-applied it.  I did some technical writing on it
> so it is not verbatim.  You can examine the note here:
> http://www.yoctoproject.org/docs/1.6/adt-manual/adt-manual.html#optionally-
> building-a-toolchain-installer.
> 
> I flipped the "Documentation change" field to "Done".  Let me know if the
> note works.

These changes looks much better. Thanks !
 
> Here is the commit URL:
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/commit/
> ?id=91409d77d68e55f4089cab3e7f48dd385dddff2

I guess, We can change the status to "Resolved".

> Thanks, 
> Scott

Thanks and Regards,
Maxin

Nice... Thanks for the quick review!

Scott