Peter da Silva wrote:
So what does "invalid operation" mean, besides the very act of running
g++ under RHEL?
I guess it's probably errno 22:
22 EINVAL Invalid argument. Some invalid argument was supplied. (For
example, specifying an undefined signal to a signal(3) function
or a kill(2) system call).
Something in the object module is confusing GCC.
Right. That's why it fails when I pass the module. What I would like to know is
(1) why can't gcc on RHEL work with an ELF shared object compiled on SuSE,
although nm, objdump & dlopen/dlsym on RHEL all agree that the object is kosher
and (2) which function got which invalid argument. Telling that some argument to
some function is wrong is less than helpful.
P.P.S. why does RHEL (or RHEL's tcsh, or some other sub-sucker of a larger
sucker) lists terminated jobs after the command following a kill command, and
not when they are actually terminated?
Because it finds out that they've terminated when it performs a wait() system
call, and it does that after running a command.
Right. They made me implement a Unix-like shell once, so I happen to know the
sacred protocols of Unix job control, so I've guessed the scenario you suggest.
I couldn't care less as a user though. As a user, I like the behavior of
t...@suse (and all other shells I've used) - saying that it killed something
right after it did so. Why is t...@rhel different?
P.P.P.S. why is tcsh located in different places in SuSE and RHEL?
Because Linux is not an operating system. It's a kernel. A Linux distribution
is a Linux kernel and a collection of packages, and it's up to the distribution
to decide what packages are there and where they go.
Why do you care where tcsh is anyway?
Right. I know that. I know that it can look whatever it likes because that's the
way they distribute it and still have Linux somewhere in it's guts. I'm not
saying that either RHEL or SuSE should avoid using the name "Linux". I'm saying
that since they ship two similar things, it would be very /nice/ of them to
avoid introducing inconsistencies for the sake of it. And the piece of shite
called tcsh should lay where it was dropped the first time someone decided to
litter a storage device with it's copy.
I don't care where tcsh is. The scripts running it with #!/bin/tcsh or the like
do care, though. I manually change that to #!/bin/env tcsh each time I bump into
it - hasn't failed me yet, although according to some replies I got here, it
surely can fail.
