[ please CC me, I'm not subscribed to the list, I only saw your reply by chance in the archives because I wanted to link this thread somewhere ]
Breno Leitao wrote: > On 04/03/2016 06:54 PM, Christian Seiler wrote: >> Well, you can just compile any number of standard programs (that don't >> require external libraries) with it. Just use diet in front of gcc, e.g. > > Right. This is working fine. No problem found running the static binaries > generated. Great. :-) >> If you want to try a real world use cases, you could try building mksh >> from sid with dietlibc-dev installed (you will need to update the >> Build-Depends in debian/control and add ppc64el to the list if you use >> an autobuilder). Then you could try running the statically linked mksh >> variant (/bin/mksh-static in the package) and doing a few things in >> the shell... > > Yea. Static mksh is running fine also. I tested it in normal mode and in > the restricted mode. > >> Warning: mksh will try to link mksh-static against something else if >> dietlibc fails, so check the build logs. (There's a summary at the >> end.) > > Right. The build seems to happen properly, and I can see: > > cp builddir/static/mksh debian/mksh/bin/mksh-static > .. > Dependencies: > | dietlibc-dev 0.34~cvs20160402.1-1~exp2+ppc64el.1 > .... > Build information for static mksh > set -A check_categories -- shell:legacy-no int:32 smksh binsh convfds > no-histfile > gcc (Debian 5.3.1-13) 5.3.1 20160323 > Result: regressed (broken<firstbuilt<checked<unattended<regressed) > Regression test results: > | Total failed: 0 > | Total passed: 506 > Variables used: > | CC='klcc' Yeah, so CC='klcc' means that this mksh was built against klibc instead of dietlibc. CC='diet gcc' or CC='diet cc' would indicate dietlibc... So you just verified that mksh with klibc works. :-) Ah, I just saw: mksh seems to prefer klibc when available, which is not all archs, and only uses dietlibc there. Now Thorsten probably has a good reason why klibc is preferred where available, but at least for testing purposes it might be nice to build against dietlibc. Just remove the libklibc-dev Build-Depends and try again; if you build it on your own system and not in e.g. pbuilder, please remove the libklibc-dev package first before building the mksh, otherwise it will default to it regardless. Would be interesting to see if that works. >> Or, you could manually compile something without external deps such as >> pwgen. (apt-get source pwgen; cd pwgen-*; ./configure CC="diet gcc"; >> make; ./pwgen to test it.) > > Package pwgen is also working fine. No error on compiling or testing it. Great! :-) I just removed a bit of useless code from the startup code of dietlibc, which was left over from my experiments. In a qemu environment this seems to work well, but could you test that on real hardware? I've pushed a patch that removes the lines I deem probably useless to git (same branch, [1]), it would be great if you could test this stuff again. Also, should I add the global entry trampoline and then .localentry to all assembly functions that might be called from C code, especially all syscalls? (syscalls jump to __unified_syscall, which could call __errno_location, which will then try to access a global variable, which uses the TOC register r2 internally.) And while technically r2 should remain constant throughout execution of a statically linked program, the spec says that if you don't have a local entry point (st_other == 0), you can't rely on r2 - so if I'm reading what my code currently does correctly is that it kind of relies on undefined behavior here? Or is there some other guarantee that the current code will work in all cases? Anyway, thanks a lot for your responses so far. Regards, Christian [1] https://anonscm.debian.org/cgit/collab-maint/dietlibc.git/commit/?h=ports/ppc64el
signature.asc
Description: OpenPGP digital signature
