Back to Operating Systems Home Page
To: Julien Faucher <julienf@ugrad.ece.mcgill.ca>
Cc: marka@ee.mcgill.ca
[ Mark, Cc: to you in case you get these questions again - I just found
in my mbox an email from you about this problem sent two days ago, sorry
for the late reply ]
> Do you think it might help to send a broadcast e-mail about the -rdynamic
> (gcc) option that solves the task_err problem?
Just done, thanks for the suggestion, and kudos for having found
it. This little problem puzzled me too at first, since the other
ports of gcc that I normally use (on IRIX-5/32 and IRIX-6/64) don't
need it -- the reason being that their linker/loader is way smarter
than linux's one.
The solution I mentioned this morning in class, i.e. linking the switcher
against the task .so files works for me too, but it's really a kludge.
> BTW, why is it that the
> -soname option and the -rdynamic option are not in the man page for gcc?
Essentially because they are really linker options, passed by gcc down to
ld. This is strictly true for -soname: the comma-separated list
following -Wl option of gcc is passed directly to the linker, after
replacing the commas with spaces (you can see this if you gcc -v). No
other processing is done on it by the compiler proper.
The -rdynamic option is slightly different. It seems to have been
introduced as a high-level interface to the linker, to (a) force the
allocation of a global symbol table in the final executable, even if it's
not strictly needed, and (b) cause the inclusion of the global symbols in
that symbol table.
o Under linux, gcc interprets it by setting the
"-export-dynamic" option for ld, which has that effect, according
to the linux ld manpage.
o Under IRIX it's ignored, and the program's happy as a clam.
o Under SunOS-4.1, gcc interprets it by setting the -dc -dp
options for ld, which again forces the allocation of the symbol
table in the code produced (see ld(1) on a Sun).
Wonder if we should mailbomb gcc-bug@gnu.org until they fix their man/info
pages ;-)
Ciao
Franco