SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Location: Geneva - Switzerland ( Bordeaux - France / Montreal - QC - Canada)
Distribution: Slackware 14.2 - 32/64bit
Sorry, it's been a while. I had other things to work on on Window$ system and couldn't really check this since last week.
Anyway I tried to check the ubuntu stuff I found last time, but honestly I'm quite lost into that ubuntu patch list, (and I haven't much time to spend on this too), I've seen few things that "looks like but are not", I think what I'd really need is to forget about the diff but trying to trace into the 'signal' call to see what parameters are sent to the kernel system call by glibc, and try to figure out why it's broken.
Right now I don't have time to look into this, but a quick thinking makes ask if the debug infos are provided in the slackware standard build. I'm afraid that I'll have to patch the slackbuild to do this (the easy part) and rebuild the whole stuff to have access to the source file symbols... Maybe it's the way to go, and in a sense I'd rather do that, than trying to understand a distro I'll never use .
Of course if someone is brave enough, have the time, and have the knowledge of both ubuntu and slackware builds internals, and can find a clue the diff way, you're welcome ! (Yes that's an if with a lots of 'ands'... )
Distribution: slackware64 13.37 and -current, Dragonfly BSD
I too haven't had time to examine this, (although I want to as these are the types of problems that fascinate me), so good luck and please do keep us posted on any findings. I will do likewise if I get the time to explore this some more.
Like I said before, I've no idea what I'm doing or looking for, but it's interesting ( if that makes any sense to anyone else ). If the name of any of those files offers a clue to anybody, I'll post it.
Ok, I may be barking up completely the wrong tree here as I'm totally out of my depth. but I got to thinking that perhaps it's a header issue so I started poking around....
This is the definition of sigaction from slackware's /usr/include/bits/sigaction.h which is #included from /usr/include/signal.h
/* Structure describing the action to be taken when a signal arrives. */
/* Signal handler. */
/* Used if SA_SIGINFO is not set. */
/* Used if SA_SIGINFO is set. */
void (*sa_sigaction) (int, siginfo_t *, void *);
# define sa_handler __sigaction_handler.sa_handler
# define sa_sigaction __sigaction_handler.sa_sigaction
/* Additional set of signals to be blocked. */
/* Special flags. */
/* Restore handler. */
void (*sa_restorer) (void);
Now, here's the def from /usr/src/linux/include/asm-generic/signal.h:
Notice the different types (highlighted red). This may be perfectly valid, but as sa_flags comes directly before sa_restorer, which is the value we're having issues with it got me wondering. Also, sa_mask seems to come in a different place within the struct.
Brian, can you please compare these with the header files on on ubuntu, to see whether there's a cat in my tree or not.
GazL, you may be on to something with the difference in the headers. ubuntu patches the kernel headers because of some which are missing from a normal 'make headers_install' command -they may also be overwriting or patching the signal.h file
You might try a quick test by changing this:
unsigned long sa_flags;
in your /usr/include/bits/sigaction.h.
Ahh ok. I guess Ubuntu isn't the best of comparisons since they make so many changes to it. Thanks for putting in the effort.
Thanks for that. I'm not sure it's as simple as that though. Firstly, the sa_mask member of struct sigaction appears to be in different order between those two head files (before sa_restorer in one, and after in the other). Also, if any of the signal handling routines within libc.a change those structures, and if libc.a was built using a defective header then that will probably also need rebuilding once the header has been corrected as that error will have already been compiled into the library objects.
As Ubuntu isn't such a good basis for comparision, I might invest a little time and see if I can do the first few steps of a LFS install to get as clean a library/headers as I can for comparisons sake.
Might take me a while though, so anyone else looking at this please feel free to do your own investigations. I'll report back if I find anything interesting.