This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Solution to --> Re: dlopen() bug on Linux/Alpha
- To: egcs-bugs at cygnus dot com
- Subject: Re: Solution to --> Re: dlopen() bug on Linux/Alpha
- From: rth at cygnus dot com (Richard Henderson)
- Date: 14 Jan 1998 21:52:28 -0800
- Newsgroups: cygnus.egcs.bugs
- Organization: Cygnus Solutions
- References: <199801110415.XAA04707@harrison.blueskyprod.com>, <199801110859.JAA12769.cygnus.egcs.bugs@kotter.atko.at>
In article <199801110859.JAA12769.cygnus.egcs.bugs@kotter.atko.at>,
Stefan Traby <stefan@sime.com> wrote:
>Please check another special condition: Make a simple program
>which does dlopen and dlsym (no, don't call main :-) on itself.
>Simplified I mean dlopen(argv[0],...) but argv[0] may not contain
>the full path...
>Does it work ?
If the main program is a regular executable (ET_EXEC), then no
it won't because dlopen will reject all but shared objects (ET_DYN).
If the main program is a shared object (yes this is possible),
then the open will succeed. It would of course be a bit pointless
but it would work.
>On a non glibc GNU-Linux/i386 system, linking with "-shared" makes the
>program dump core _before_ main is called. SIGSEGV "#0 0x4 in ?? ()"
This is only because the libc5 startup code is not sufficiently agile.
As I said, it is quite possible to directly execute shared objects.
r~