Re: [Mingw-users] Undefined references linking to a dll with GCC 3.2.2 & dllwrap

[<Gav...@sp...>]

Hi Danny,
Thanks for the response!  Half the problem I am having is that I am not
entirely sure what I am doing, as this is the first time I have tried
creating a dll using MinGW.

Given the length of me email I thought I would add a quick summary of the
rest of my email here:
* Do I have to remove the __declspec(dllexport) & __declspec(dllimport)
attributes when using gcc -shared?  Or will gcc just ignore those
attributes when I use the -shared flag?
* Do I have to pass in the exact same flags when using gcc to link the dll
as I do when compiling the dll?  For example, if I use "-mthreads
-mno-cygwin -mms-bitfields -O3" to compile the cpp files, do I then pass "
-mthreads -mno-cygwin -mms-bitfields -O3" to gcc when linking the dll?
* If I use -mnocygwin do I need to specify "--target i386-mingw32" when
calling gcc?  If I include this flag when linking the dll, I receive an
error message from ld saying it cannot find crtbegin.o.  I have set the
GCC_EXEC_PREFIX variable to point to c:\mingw\lib\gcc-lib, which from
everything I've found on the net so far this should fix the problem (but
doesn't for me).  If I leave of the target flag, it links correctly.

A summary of my attempts to build the dll & executable to date:
The icuin.dll  was built by defining the __declspec(dllexport) on all the
classes (this is the default action of the source from IBM).  However, this
did not export all the class functions or static member variables due to a
lot of the classes referencing each other with the "friend class XXX"
statement.  These friend statements do not have the __declspec(dllexport)
added to them, and were suffering from the problem you described below.  I
read up on this problem on the net, and the suggested fix was to use
--export-all-symbols.

So I recompiled the dll using --export-all-symbols.  Examining the dll
using pexports or nm I can see all the symbols have been exported.

I then compiled the intltest.exe program, using --enable-auto-import.  I
did not know that the --enable-auto-import option was not compatible with
dlltool built dlls.  I ended up putting this in the build of intltest.exe
after using "gcc --target-help" & "dllwrap --help" etc in the hope this
would fix the problem.

I have been using the Dev-CPP build environment to build the dlls &
executables.  This by default uses dllwrap to create DLLS.  When I specify
to use gcc to link the dll, the Dev-CPP environment still adds "
--output-def libicuin.def --driver-name c++" to the call as it thinks it is
calling out to dllwrap.  This causes the compile to fail (it complains
about the "c++" in "--output-def libicuin.def --driver-name c++").  The end
result of this is I am now back to using the command line & makefiles until
I can work this problem out in Dev-CPP.

In the makefile, I know how to create the DLL output using gcc (e.g. gcc
-shared -o MyDll.dll file1.o file2.o) but I don't know what other command
line arguments to pass in.  For instance, if I compiled all the CPP files
using "-mthreads -mno-cygwin -mms-bitfields -O3", should I pass these exact
same flags into gcc when outputting the DLL?  I have yet to find this out
from looking through the online GCC manual.

As I mentioned in my original email, the DLL is using the #define
U_I18N_APi to hide the __declspec(dllexport) & __declspec(dllimport).
Should I define U_I18N_API to nothing if I am using -shared?  In other
words, if I am using gcc -shared, will the __declspec(dllimport) &
__desclspec(dllexport) attributes be ignored?

When do i have to use the "--target i386-mingw32" flag?  If I use this
flag, ld fails to find crtbegin.o when linking the dll despite setting the
GCC_EXPORT_PREFIX environment variable.  From what I have read online, I
should be able to set this environment variable to the lib\gcc-lib
directory of mingw installation to solve this problem, but it has not done
so for me.  Perhaps I am just not meant to use that flag?

This is foreign territory for me here, because all other compilers on the
Windows platform that I have used have required me to put the
__declspec(dllimport) & __declspec(dllexport) attributes on the classes etc
in the dll.  I can't seem to find any documentation via google on whether I
should use not use the __desclspec() attribute with -shared.


Regards,
--
Gavin Oliver


|---------+---------------------------->
|         |           Danny Smith      |
|         |           <dannysmith@clear|
|         |           .net.nz>         |
|         |                            |
|         |           15/04/2003 09:37 |
|         |           PM               |
|         |           Please respond to|
|         |           Danny Smith      |
|         |                            |
|---------+---------------------------->
  >------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                              |
  |       To:       min...@li..., Gav...@sp...                                                |
  |       cc:                                                                                                                    |
  |       Subject:  Re: [Mingw-users] Undefined references linking to a dll with GCC 3.2.2 & dllwrap                             |
  >------------------------------------------------------------------------------------------------------------------------------|





----- Original Message -----
From: <Gav...@sp...>
To: <min...@li...>
Sent: Tuesday, 15 April 2003 07:02
Subject: [Mingw-users] Undefined references linking to a dll with GCC
3.2.2 & dllwrap
..snip ..snip.....
> From this I gather the problem is entirely with the linking of the
final
> executable, not the DLL I built.  Is this correct?
>
> I have read in an earlier posting that I should either add
> __declspec(dllimport) to each static member variable (something I
cannot
> do) or use gcc -shared to build the import lib & dll.  How on earth do
I do
> that?  I just use the Dev-CPP program to take care of the makefiles
etc,
> and I have no idea on how to use gcc to make a DLL versus dllwrap.
>
> Shouldn't the dlltool correctly link the static member variables,
given
> that the class they belong to has been correctly flagged with the
> __declspec(dllimport)?  Is this considered a bug in the dlltool?  What
can
> I do to fix this?

1)  --enable-auto-import  does not work with import libs created with
dlltool.  The magic is simply not there.  Thats's why the  strange
undefined references to _lib_*_a_iname.  If you want to use auto-import
you need to create your import libs with g++/gcc -shared

2) Since, as I understand, you marked imported classes with class
__declspec(dllimport), you should not need to use auto-import.  However,
there is a bug in gcc 3.2.x . It shows up if you do something like this:

class __declspec(dllimport) foo
 {
    ....  members....
};

and later do  a "forward" declaration without the dllimport attribute:

class foo;

and then use the class.

The second declaration (without attribute) overrides the  attributed
declaration so tha dllimport is lost. This means that  static data
members of the class are no longer marked as dllimport.

 I honestly do not know when you can expect a fix for that bug.   There
are other problems with RTL frobbing of dllimport-encoded names that
show up with vtables.

Its all too confusing for me.  Recent changes in the handling of decl
attributes may eventually make this whole area less fragile.  But it
needs some work.

if you could reduce the problem to a self-contained testcase, it would
avoid a lot of guesswork about what your problem really is about, and
that in itself would speed up a solution.

Danny



>
> Each .cpp file in the test application intltest.exe was built with the
> following command (taking the one output line as an example of how all
cpp
> files were built):
> g++.exe -c allcoll.cpp -o allcoll.o -I"C:/MinGW/include/c++"
> -I"C:/MinGW/include/c++/3.2.2/mingw32"
> -I"C:/MinGW/include/c++/3.2.2/backward"  -I"C:/MinGW/include"
> -I"../../../source/common"  -I"../../../source/i18n"
> -I"../../tools/toolutil" -D__GNUWIN32__ -mcpu=pentiumpro -D_M_IX86=600
> -ansi -fexceptions -fno-inline -DWIN32 -DNDEBUG -D_CONSOLE -D_MBCS
> -mthreads -mno-cygwin -mms-bitfields -O3
>
> The output of gcc -v is:
> Reading specs from c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/specs
> Configured with:
../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
> --host=mingw32 --target=mingw32 --prefix=/mingw
>  --enable-threads --disable-nls --enable-languages=c++,f77,objc
> --disable-win32-registry --disable-shared --enable-sjlj-
> exceptions
> Thread model: win32
> gcc version 3.2.2 (mingw special 20030208-1)
>
> The executable was linked with the following command:
> g++.exe allcoll.o apicoll.o biditst.o callimts.o calregts.o caltest.o
> caltztst.o canittst.o citrtest.o cntabcol.o cpdtrtst.o cppcnvt.o
currcoll.o
> dacoll.o dadrcoll.o datamap.o dcfmapts.o decoll.o dtfmapts.o
dtfmrgts.o
> dtfmtrtts.o dtfmttst.o encoll.o escoll.o ficoll.o frcoll.o g7coll.o
> hxuntrts.o icusvtst.o intltest.o itconv.o itercoll.o itformat.o
itmajor.o
> itrbbi.o itrbnf.o itrbnfrt.o ittrans.o itutil.o jacoll.o jamotest.o
> lcukocol.o loctest.o miscdtfm.o mnkytst.o msfmrgts.o nmfmapts.o
nmfmtrt.o
> normconf.o numfmtst.o numrgts.o pptest.o rbbiapts.o rbbitst.o
regcoll.o
> regextst.o reptest.o restest.o restsnew.o sdtfmtts.o sfwdchit.o
srchtest.o
> strcase.o strtest.o tchcfmt.o testdata.o testutil.o tfsmalls.o
thcoll.o
> tmsgfmt.o transapi.o transrt.o transtst.o trcoll.o trnserr.o tscoll.o
> tsdate.o tsdcfmsy.o tsdtfmsy.o tsmthred.o tsmutex.o tsnmfmt.o
tsputil.o
> tstdtmod.o tstnorm.o tzbdtest.o tzregts.o tztest.o ucaconf.o ucdtest.o
> ufltlgts.o unhxtrts.o uobjtest.o usettest.o ustrtest.o  -o "..\..\..
>
\bin\intltest.exe" -L"C:/MinGW/lib" -L"C:/MinGW/lib/gcc-lib/mingw32/3.2.
2"
> -L"../../../lib" -licuin -licuuc -licutu  --mno-cygwin --enable-auto-i
mport
> --enable-runtime-pseudo-reloc
>
> Info: resolving __ZN7icu_2_417RuleBasedCollator16PRIMARYORDERMASKE by
> linking to __imp___ZN7icu_2_417RuleBasedCollator16PRIMARYORDERMASKE
> (auto-import)
> Info: resolving __ZN7icu_2_417RuleBasedCollator17PRIMARYORDERSHIFTE by
> linking to __imp___ZN7icu_2_417RuleBasedCollator17PRIMARYORDERSHIFTE
> (auto-import)
> Info: resolving __ZN7icu_2_417RuleBasedCollator18SECONDARYORDERMASKE
by
> linking to __imp___ZN7icu_2_417RuleBasedCollator18SECONDARYORDERMASKE
> (auto-import)
> Info: resolving __ZN7icu_2_417RuleBasedCollator19SECONDARYORDERSHIFTE
by
> linking to __imp___ZN7icu_2_417RuleBasedCollator19SECONDARYORDERSHIFTE
> (auto-import)
>
> Info: resolving __ZN7icu_2_417RuleBasedCollator17TERTIARYORDERMASKE by
> linking to __imp___ZN7icu_2_417RuleBasedCollator17TERTIARYORDERMASKE
> (auto-import)
> Info: resolving __ZN7icu_2_417RuleBasedCollator13PRIMIGNORABLEE by
linking
> to __imp___ZN7icu_2_417RuleBasedCollator13PRIMIGNORABLEE (auto-import)
> Info: resolving __ZN7icu_2_413BreakIterator4DONEE by linking to
> __imp___ZN7icu_2_413BreakIterator4DONEE (auto-import)
> Info: resolving __ZN7icu_2_410UnicodeSet9MAX_VALUEE by linking to
> __imp___ZN7icu_2_410UnicodeSet9MAX_VALUEE (auto-import)
>
> fu000001.o(.idata$3+0xc): undefined reference to
> `______lib_libicuin_a_iname'
> fu000003.o(.idata$3+0xc): undefined reference to
> `______lib_libicuin_a_iname'
> fu000005.o(.idata$3+0xc): undefined reference to
> `______lib_libicuin_a_iname'
> fu000007.o(.idata$3+0xc): undefined reference to
> `______lib_libicuin_a_iname'
> fu000009.o(.idata$3+0xc): undefined reference to
> `______lib_libicuin_a_iname'
> fu000011.o(.idata$3+0xc): more undefined references to
> `______lib_libicuin_a_iname' follow
> fu000013.o(.idata$3+0xc): undefined reference to
> `______lib_libicuuc_a_iname'
> fu000014.o(.idata$3+0xc): undefined reference to
> `______lib_libicuuc_a_iname'
> fu000015.o(.idata$3+0xc): undefined reference to
> `______lib_libicuuc_a_iname'
> fu000016.o(.idata$3+0xc): undefined reference to
> `______lib_libicuuc_a_iname'
> fu000017.o(.idata$3+0xc): undefined reference to
> `______lib_libicuuc_a_iname'
> fu000018.o(.idata$3+0xc): more undefined references to
> `______lib_libicuuc_a_iname' follow
> nmth000000.o(.idata$4+0x0): undefined reference to
> `_nm___ZN7icu_2_417RuleBasedCollator16PRIMARYORDERMASKE'
> nmth000002.o(.idata$4+0x0): undefined reference to
> `_nm___ZN7icu_2_417RuleBasedCollator17PRIMARYORDERSHIFTE'
> nmth000004.o(.idata$4+0x0): undefined reference to
> `_nm___ZN7icu_2_417RuleBasedCollator18SECONDARYORDERMASKE'
> nmth000006.o(.idata$4+0x0): undefined reference to
> `_nm___ZN7icu_2_417RuleBasedCollator19SECONDARYORDERSHIFTE'
> nmth000008.o(.idata$4+0x0): undefined reference to
> `_nm___ZN7icu_2_417RuleBasedCollator17TERTIARYORDERMASKE'
> nmth000010.o(.idata$4+0x0): undefined reference to
> `_nm___ZN7icu_2_417RuleBasedCollator13PRIMIGNORABLEE'
>
> nmth000012.o(.idata$4+0x0): undefined reference to
> `_nm___ZN7icu_2_413BreakIterator4DONEE'
> nmth000045.o(.idata$4+0x0): undefined reference to
> `_nm___ZN7icu_2_410UnicodeSet9MAX_VALUEE'
>
> make.exe: *** [../../../bin/intltest.exe] Error 1
>
> Execution terminated
>
> Regards,
> --
> Gavin Oliver











This email (including any attachments) is intended only to be read 
or used by the addressee. It contains information that may be 
confidential and legally privileged. If you are not the addressee, 
or you have received this email by mistake, you must not disclose, 
copy or distribute it or use the information contained in it (or any 
attachments) in any way.

If you have received this message in error please notify Sparke 
Helmore by return email or reverse charges telephone call to 
+61 2 9373 3555 and then delete this message and any copies 
of it. Please also contact us if you have any doubts about the 
authenticity of this email.

Any legal professional privilege between solicitor and client, or any
other rights, are retained by Sparke Helmore and are not lost or 
waived because you have received this message in error. This 
email (including any attachments) may also contain computer 
viruses or other defects. Sparke Helmore is not liable for any loss 
or damage that may be caused by these viruses or defects.