Re: mingw DLL problem

> I still can't figure out how to make it work.
>
> Consider the file  "foo.cc"
> =========
> extern int bar();
> int foo(int q)
> {
>  return q*bar();
> }
> =========
>
>
> On Linux, to make a native .so I can do:
>        g++ -fPIC --shared foo.cc
> and it builds an appropriate file, such that "bar" will be
> resolved later.
>
>
> The problem is if I do:
>        i586-mingw32msvc-g++  --shared foo.cc
> It responds with:
> ========
> /tmp/cch3JG6k.o:foo.cc:(.text+0x7): undefined reference to
> `bar()'
> collect2: ld returned 1 exit status
> ========
>
> With a real file, I get a flood of these messages.
> What am I doing wrong?

Hi Al,
 	I don't mean to nag about this again :), but this sort of problem 
is intended for GNU libtool, whose collection of configure-time checks 
will answer these questions and more for you (and anyone else) on these 
platforms, and just Do The Right Thing (TM).  I strongly recommend 
libtoolizing the build, or at least playing around with a toy example to 
see what it deduces on the target platform.
 	I happen to have a small tutorial/test-case tarball handy, if 
you'd like a (hopefully unintimidating) example to play with:

http://www.csl.cornell.edu/~fang/sw/ltdl_test-0.0.1.tar.bz2

(same test case I presented in a [email protected] thread:
http://lists.gnu.org/archive/html/libtool/2007-08/msg00014.html)

This demonstrates plug-in modules done with libtool's libltdl.  The test 
program loads plug-in libraries based on command-line arguments, and 
confirms each module that is found and loaded.  2 of the tests in the 
small test-suite are known to fail on darwin (intentionally exposes a 
difference in rpath-ness between platforms).  I don't have a mingw system 
to test, so I might learn something new from your testing of this.

best,


Fang



David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
 	-- (2400 baud? Netscape 3.0?? lynx??? No problem!)