This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: help with dynamic linkage?


On Sat, 2006-02-11 at 00:59 -0500, Igor Peshansky wrote:
> On Sat, 11 Feb 2006, skaller wrote:
> 
> > hi, I'm having some problem getting dynamic linkage to work.
> > The linkage model is like this:
> >
> > mainline <----- load time ---- librtl.dll
> > ^                               /
> >  \                             /
> > dlopen                        /
> >    \                         /
> >   user.dll <-----------------
> >
> > gdb indicates the code is crashing in dlopen. LoadLibrary
> > doesn't appear to work either :)
> >
> > All the code is C++. It works on Linux, it works with
> > the option -mnocygwin, and it works with MSVC++.
> 
> You mean "-mno-cygwin", right?

Yes, sorry, my build scripts call that platform 'nocygwin'.

> It would help if you told us what linker switches you're using. 

No special switches, just -L and -l.

>  In fact,
> a small example program, buildable with a makefile into two DLLs and a
> main application, would be even more helpful.

I have tried that .. it works :) Basically the original instructions
on the website say to use -Wl,-auto-import ... blah blah in the advanced
explanations suff. But the simplified example doesn't use that.
Neither do I. I did try building an export/import lib. That does seem
to change the time and way the system crashes.

The crash occurs when an attempt is made to load the user.dll,
even when the filename given is rubbish .. so the problem isn't
related to that dll. The program WORKS when no filename is
given, in which case it just prints the usual 'usage' information.

In the case of a garbage filename, the rtl should be throwing
a C++ exception. Perhaps that's causing the problem. However 
in the case of a valid filename it should work .. but I get
the same result.

Unfortunately the only easy way to reproduce the problem is to
download and install Felix:

	http://felix.sf.net/flx_1.1.2_rc1.tgz

which requires Python and Ocaml. After that ./configure, make
should work. Then make test. BTW: if any Cygwin expert would
like to join the project that would be great!

> Then wouldn't you be able to reproduce it with only one DLL and one main
> application?  Can we see a small complete example that shows the problem?

As above .. small C example, as given on the Cygwin website, works
just fine. 

The problem could be related to C++ RTTI, since I know
ELF/gcc 4.0 doesn't work correctly it would be unfair to expect
gcc 3.4 on Cygwin to do all that nasty emulation and work.

(The problem here is related to duplicate typeinfo records,
which cannot be avoided in general with dynamic linkage.
Some care is needed in the code to ensure the RTTI is only
instantiated once, and properly imported from that one
location, because gcc's method of catching exceptions 
is broken)

However no exception should be thrown when loading one
of the proper dlls with dlopen(), so there could be
two distinct faults.

It's also possible -O3 -fomit-frame-pointer is the problem:
gcc's -O3 is known to not work reliably. (however if I recall
I got rid of both, and it made no difference).

> > Info: resolving vtable for XXXby linking to __imp__XXX (auto-import)
> >
> > occur when linking the executable.
> 
> Those are informational.  You can either ignore them, or give the
> "-Wl,--enable-auto-import" flag to the linker to quiet them.

I admit being confused what that does. According to my understanding
of it, this auto-import thing should only apply to variables.
vtables and code are read only, they should be in the code (text)
segment shouldn't they?

> > Cygwin: latest setup provides.
> 
> Umm, setup can provide quite a few versions ranging from ancient to
> latest, depending on your mirror.  Why not follow the guidelines at
> <http://cygwin.com/problems.html> and attach (as an uncompressed text
> attachment) the output of "cygcheck -svr"?

Done, for the XP64 machine. The other I can't get atm, since
its dual booted with Linux which is running my mail client :)

> > Any hints what is causing the problem or how to fix it?
> 
> Not until we have enough information to allow us to reproduce the problem.

I need some hint of what it could be to try to reduce
the 100KLoc to a manageable size :) It has to be something
related to different ways Linux and Cygwin handle dynamic linkage,
interacting with some other feature -- such as threads, exception
handling, linkage technique/dll startup code, etc etc.

One difference: on Linux I have to use -lpthread, on Cygwin
that seems unnecessary. I did try rebuilding with it.

> FWIW, I was unable to reproduce this with a trivial instance of your
> scheme above and default linker options.

Neither was I.

>   One quick question: how are you
> invoking functions from user.dll, are you getting the right function
> pointer, and are you taking care of C++ name mangling when loading symbols
> from the DLL?

I think so: it works on Linux, OSX, -mno-cygwin, MSVC++ etc. 
All the dlsym() symbols are extern "C". 

However, the rtl is not dlopen()ed.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Attachment: cycheckout.txt
Description: Text document

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]