LinuxQuestions.org - Slackware 64 - Static compilation broken !

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Slackware 64 - Static compilation broken ! (https://www.linuxquestions.org/questions/slackware-14/slackware-64-static-compilation-broken-803845/)

I wonder if the cryptsetup issue is also related to this:
From the changelog:

Quote:

a/cryptsetup-1.1.0-x86_64-1.txz: Upgraded.
Moved the libraries to /lib{,64}, and removed the static binary, which wasn't working right anyway.

I tried asking on this forum what the underlying issue with it was back when the issue first surfaced but never got a response, and I let the issue drop thinking that sooner or later an updated package would come along to fix it. Now it seems we have evidence of a few other cases of statically built programs not working correctly on Slackware64.

I'm not very comfortable with this somewhat 'pragmatic' approach of just removing the offending static binary. If as it now seems there's a wider issue at work here with the static libraries then one can't have confidence that the system is going to be a solid foundation to build on.

I hope the devs take an interest in this. I'd hate to have to revert to the 32bit version now.

The static cryptsetup binary segfaulted on x86_64... and for certain commands only. This also happened on other distros, even the bigger ones, no one found out why, and the static binary has been dropped from all distros. I think we were the last to drop the static cryptsetup.

If you can find why a 64-bit binary crashes when returning from a signal handler then I'll gladly look at your patch. If not, then there is not going to be any change to Slackware64. You are on top of this problem and it'll be easier for you (as software developers or at least savvy with debuggers) to find the bug than any of the Slackware team.
We are simply to small a team to be bothered with bugs like these, unless someone writes the patch to fix it.

Eric

Quote:

Originally Posted by GazL (Post 3956858)

I wonder if the cryptsetup issue is also related to this:

I thought exactly the same thing seeing the change log. And had the same idea about the solution chosen.

Quote:

Originally Posted by GazL (Post 3956858)

I hope the devs take an interest in this.

I have an important interest in it : developping a cross platform C++ framework that requires static linkage for design/constraints reason.

Quote:

Originally Posted by GazL (Post 3956858)

I'd hate to have to revert to the 32bit version now.

Yes that's my point too...

Note that I took the liberty to ask to Patrick ("The One" :) ), and he was kind to answer me, but couldn't help at that time:

Quote:

[...]
Really, if the folks on LinuxQuestions couldn't help, you may be forced to become your own expert. If it leads to identifying some bug in Slackware, though, please let me know.

All the best,

Pat

(Of course I did MANY backup of this precious email ;) haha )

Anyway I should be able to find the problem, but I'm lacking of too many infos here, and so few time, so I'd "just" need some help/clues from some dudes that could handle that.

Moreover I really want to promote Slackware as a dev os, and I'd be happy to be able to showcase 64bit demos ;).

Cheers.

Quote:

Originally Posted by Alien Bob (Post 3956974)

We are simply to small a team to be bothered with bugs like these, unless someone writes the patch to fix it.

Eric

Yes, I appreciate that Eric and figured resource would be an issue. Though I can do a little debugger work, once it gets to the level of looking at library internals I'm also somewhat out of my depth.

I know Garry said Ubuntu doesn't suffer this same problem so I'm wondering what version of glibc that's running. If we can identify this as library version specific rather than slackware specific, that would give us something to go on and maybe even getting upstream to take an interest.

Anyone running any other 64bit distro that use glibc 2.11 and demonstrates this same issue, or not?

Quote:

Originally Posted by GazL (Post 3956990)

Anyone running any other 64bit distro that use glibc 2.11 and demonstrates this same issue, or not?

That's what I first tried, but I might have lost my temper quickly :) LQ - Programming

I've also tried glibc-help mailing list (my first call for help in fact), I first tried to explain the crash, the only answer I had was an ask for a test case, which I wrote, but no more answer. Then on the LQ's programming forum, it seems to me I had more answers on "basics concepts" than on the "real deal".

We need someone who understand glibc/kernel calls/64bit and who take us seriously :). But again, I should be able to track this down, if I can have some 'contextual infos' or pointers to helpful docs.

I've seen other "64bit segfault" stuff around the web but not related to that bug OR too old to be still alive in nowadays glibc (like early 2Ks). Segfaults are so common (associated with ret/q) that it's hard to pinpoint the same context on google searches.

BTW, of course I get frustrated because of this bug, but THANK YOU to the Slackware Team, we all appreciate your work and efforts.

Bests.

If ubuntu doesn't show the same behaviour, I'd get a copy of the deb/ubuntu quilt-patch for glibc and apply it to the sources. Then, cd into the debian/patches folder inside and grep for the offending function call. If it's a glibc issue something should show up in the patches.

I haven't a clue what the solution is, but I was interested, and had some free space and a Ubuntu 9.04 amd64 CD, so I thought I'd check it out. Slackware 13.0 and Ubuntu 9.04 have the same gcc and glibc versions: 4.3.3 and 2.9. All the programs, Gazl's and NoStressHQ's, static and shared, worked OK with no segmentation fault.

Quote:

Originally Posted by brianL (Post 3959856)

[...] All the programs, Gazl's and NoStressHQ's, static and shared, worked OK with no segmentation fault.

Hey brianL thanks.

So it seems it's really a slackbuild/patch somehow.

That 'diff' option sounds good but I don't know ubuntu at all. gnashley seems to have some expertise with it. Do you have time to try that ? Or what do I need to do, if I need to do it (I mean where are stored the install/patch scripts of ubuntu, sorry if this sounds stupid, but I'm quite uncomfortable with unbuntu hahaha).

Btw, Slack 13.1 beta has come, great news :)

Cheers

I haven't any experience of dealing with patches and .diff files. I got Ubuntu's glibc source, and I'm on Slack now with Ubuntu mounted on /mnt/tmp. In (Ubuntu's) /usr/src/glibc/glibc-2.9/debian/patches, there's a list of all the patches. I've had a glance at some, but I don't really know what to look for. Here's the edited list:

Code:

amd64/local-biarch.diff

amd64/local-clone.diff

amd64/local-linuxthreads-gscope.diff

any/local-asserth-decls.diff

any/local-bindresvport_blacklist.diff

any/local-allocalim-header.diff

any/local-fhs-linux-paths.diff

any/local-fhs-nscd.diff

any/local-ipv6-lookup.diff -p0

any/local-ld-multiarch.diff

any/local-ldd.diff

any/local-ldso-disable-hwcap.diff

any/local-ldconfig.diff

any/local-ldconfig-fsync.diff

any/local-libgcc-compat-main.diff

any/local-libgcc-compat-ports.diff

any/local-linuxthreads-defines.diff

any/local-linuxthreads-fd.diff

any/local-linuxthreads-gscope.diff

any/local-linuxthreads-lowlevellock.diff

any/local-linuxthreads-fatalprepare.diff

any/local-linuxthreads-ptw.diff

any/local-linuxthreads-semaphore_h.diff

any/local-linuxthreads-signals.diff

any/local-linuxthreads-tst-sighandler.diff

any/local-linuxthreads-weak.diff

any/local-localedef-fix-trampoline.diff

any/local-makeconfig.diff

any/local-mktemp.diff

any/local-no-pagesize.diff

any/local-nss-upgrade.diff

any/local-o_cloexec.diff

any/local-rtld.diff

any/local-stubs_h.diff

any/local-stdio-lock.diff

any/local-tcsetaddr.diff

any/local-disable-test-tgmath2.diff

any/local-tst-mktime2.diff

any/local-dynamic-resolvconf.diff

any/submitted-nis-netgrp.diff

any/submitted-getcwd-sys_param_h.diff

any/submitted-clock-settime.diff

any/submitted-date-and-unknown-tz.diff

any/submitted-libgcc_s.so.diff

any/submitted-longdouble.diff

any/submitted-sched_h.diff

any/local-disable-nscd-host-caching.diff

#any/submitted-fileops-and-signals.diff                # has issues

any/local-missing-linux_types.h.diff

any/cvs-bz697-posix-regexec.diff

any/cvs-bz9697-posix-regcomp.diff

any/cvs-bz9706-nss_nss-files_files-parse.diff

any/cvs-bz-9720-resource.diff

any/local-nss-overflow.diff

any/submitted-popen.diff

any/local-linuxthreads-thread_self.diff

any/cvs-pthread_h.diff

any/local-bashisms.diff

any/submitted-futex_robust_pi.diff

any/cvs-bz7058-nss_nss-nis.diff



# Ubuntu-specific patches.  These are things that we don't expect to wind up

# in Debian.

ubuntu/local-altlocaledir.diff -p1

ubuntu/stack-guard-quick-randomization.diff

ubuntu/no-sprintf-pre-truncate.diff

ubuntu/local-fwrite-no-attr-unused.diff

ubuntu/submitted-leading-zero-stack-guard.diff

Anything there that looks as if it's relevant?

I've been looking through the ubuntu diff here:
https://launchpad.net/ubuntu/+source/glibc/2.9-9ubuntu2

Signals get mentioned quite a few times. Identifying which may be relevant is the hard part. Searching for restore_rt finds quite a few hits too.

edit: Actually that restore_rt stuff appears to be specific to a motorola port (m32r), so I don't think that one is relevant.

Hey thanks brianL and GazL, I've looked the diffs in the links you sent, I note some things 'close', but I think nothing is related to our case. Yeah the rt_restore patch is for another arch (but maybe the same behavior happened on the motorola ?)

Anyway I'd be happy to apply ubuntu diff-patch on the glibc and diff both versions with a 'slack patched glibc'...

But I have a little issue: slack-current glibc has become 2.11.1 while the ubuntu diff was targeted to 2.9. So the diff between the two versions might be bloated or irrelevant. Maybe if I get an older version of slack's glibc (a 2.9) it will fit ? I give a try with slackware 13.0 one which seems to be matching.

Cheers.

It would help relative newbies (or slow, lazy learners :) ) like me, if they gave patches obvious names like stops_static_programs_segfaulting_when_shared_versions_run_ok.diff. :)

Quote:

Originally Posted by brianL (Post 3961999)

It would help relative newbies (or slow, lazy learners :) ) like me, if they gave patches obvious names like stops_static_programs_segfaulting_when_shared_versions_run_ok.diff. :)

Agreed. :) Comments in the diffs describing what they're about would also be nice. I'm a bit surprised something as vital as glibc needs quite so many patches in the first place. I start to see why the OpenBSD guys have their own libc now. Oh well. :(

Quote:

It would help relative newbies (or slow, lazy learners ) like me, if they gave patches obvious names like stops_static_programs_segfaulting_when_shared_versions_run_ok.diff.

Nah - that would make it no fun ..;)

I too have downloaded the Ubuntu source and am finding the patch structure more than a little bewildering. Not to mention running into the library calls and such like with a debugger is not the easiest debugging task. Personally I find it quite frustrating when things like this go unfixed in some versions but not others.

Not being too familiar with FOSS development models I could be missing something here but, at first sight, it looks like the Ubuntu patches, if their benefit is somewhat universal, should be passed upstream so all library users may benefit.

Anyway, enough ranting on something I'm certainly no expert in.

@NoStressHQ - Good luck with this - it would be interesting to see what fix you settle for with this and it's performance.

I don't think it's in those Ubuntu specific patches, but in those /any/*.diffs.