Jussi, > The host-side glibc in scratchbox is quite old.
Yes, I believe it's been kept at version 2.3.2 since the early releases of Scratchbox. >However, I'm beginning to think that the most sensible plan would be >just to upgrade the host-side glibc to a less ancient level. This won't really prevent this problem from happening, although it'll probably make it more rare. There is always a chance someone might compile a dynamic binary with a more recent glibc than the host-side one, and that'll likely result in a version incompatibility, again. That is, unless you keep the host-side glibc apace with the latest glibc releases. By the way, I managed to make my binary run out of /host_usr directory without having to copy any libs and loader there. To do that, I had to link all libs except libc statically, and use the same version of glibc and loader as the host-side (i.e., 2.3.2) at compile-time. However, it seems I've discovered an interesting bug in sb_alien in the process. You see, my binary is called cov-build, and it appears that sb_alien considers any binary whose filename ends with "ld" as a linker and unconditionally inserts extra arguments into its command line before executing it. Obviously, these extra arguments are not expected by my binary and interfere with its run (as would be the case with any other alien binary in place of mine, I think). I can work around this problem inside my binary, of course. However, wouldn't you say that the condition for identifying a linker in sb_alien is much too generic? Can't it be made a bit more specific to linkers in the future Scratchbox releases? Best regards, Mikhail _______________________________________________ Scratchbox-users mailing list Scratchbox-users@lists.scratchbox.org http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users