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] |
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] |