From: Christian E. <Ch....@gm...> - 2005-05-21 17:39:01
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, once more I've got a problem with ld. I want to link direct to a dll but ld does not find the symbols because the dll only exports the functions without '@nn'. Is there a way to tell ld to automatically remove this? Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCj3ImnNKwkgf+zVMRAoicAKCHqzq3jtEUPq5P2QSlxaR/Sw36cwCgmOJ7 /2GFN583xRF127Z/Dcmbz2I= =AhcB -----END PGP SIGNATURE----- |
From: Mark J. <mj...@gm...> - 2005-05-21 23:21:49
|
Christian Ehrlicher schrieb: >once more I've got a problem with ld. I want to link direct to a dll but >ld does not find the symbols because the dll only exports the functions >without '@nn'. Is there a way to tell ld to automatically remove this? > > AFAIK you have to create an import library. 1. Create a .DEF file for the .DLL path$ pexports dllfile.dll > dllfile.def (please ignore any exceptions, it's working anyway) 2. Add the missing "@n" to all needed functions 3. Run the dlltool to create the import library path$ dlltool --dllname dllfile.dll --def dllfile.def --output-lib libdllfile.a -k The important thing is the "-k". Sometimes you'll also add the "-A" option. Regards, Mark |
From: Michael G. <mg...@te...> - 2005-05-22 06:01:11
|
> once more I've got a problem with ld. I want to link direct to a dll but > ld does not find the symbols because the dll only exports the functions > without '@nn'. Is there a way to tell ld to automatically remove this? =46rom what you write I deduce the DLL in question had not been created by the MinGW toolchain but by another compiler. This might imply you'll manually have to create an importlibrary for this DLL. Check out http://www.mingw.org/MinGWiki/index.php/CreateImportLibraries for a description of what has to be done. Wether you'll need the names with or without '@nn' suffix depends on the calling convention. __stdcall definitely needs '@nn'. You'll find the calling convention by checking the headerfiles. HTH, best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Christian E. <Ch....@gm...> - 2005-05-22 07:34:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Gerdau schrieb: >>once more I've got a problem with ld. I want to link direct to a dll but >>ld does not find the symbols because the dll only exports the functions >>without '@nn'. Is there a way to tell ld to automatically remove this? > > > From what you write I deduce the DLL in question had not been > created by the MinGW toolchain but by another compiler. > > This might imply you'll manually have to create an importlibrary > for this DLL. Check out > http://www.mingw.org/MinGWiki/index.php/CreateImportLibraries > for a description of what has to be done. > > Wether you'll need the names with or without '@nn' suffix depends > on the calling convention. __stdcall definitely needs '@nn'. > > You'll find the calling convention by checking the headerfiles. The dll is a standard win32 dll (kernel32.dll) and mingw has already import libs for them. But then my problem is that I get a memory problem (see my problem 'ld memory usage') when using import libs - with direct linking to a dll, memory cosumtion is about 400MB which is huge but works fine with 512MB ram. I really can't use import libs for this. Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCkDYDnNKwkgf+zVMRAv/+AKCSm5zcyeHpLu+WOB53b4zp8thwegCfT+Ix eJ/XJQNBqqlz9d4agdWwZ78= =xpGh -----END PGP SIGNATURE----- |
From: Michael G. <mg...@te...> - 2005-05-22 07:59:31
|
> The dll is a standard win32 dll (kernel32.dll) and mingw has already > import libs for them. But then my problem is that I get a memory problem > (see my problem 'ld memory usage') when using import libs - with direct > linking to a dll, memory cosumtion is about 400MB which is huge but > works fine with 512MB ram. I really can't use import libs for this. I had read that thread without fully understanding the problem. Just to rule out the obvious: You are using a recent version of binutils (if not the most recent) !? I'm using the commercial version of Qt3 and am building it using the most recent MinGW toolchain. While creating qt-mt333.dll (or qt-mt334.dll) does indeed take both time and memory it is manageable or so I think. So to come back to your original problem 'ld memory usage': Basically you are looking for a solution to reduce linktime memory consuption of the MinGW-toolchain ? Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Christian E. <Ch....@gm...> - 2005-05-22 08:19:38
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Gerdau schrieb: >>The dll is a standard win32 dll (kernel32.dll) and mingw has already >>import libs for them. But then my problem is that I get a memory problem >> (see my problem 'ld memory usage') when using import libs - with direct >>linking to a dll, memory cosumtion is about 400MB which is huge but >>works fine with 512MB ram. I really can't use import libs for this. > > > I had read that thread without fully understanding the problem. > > Just to rule out the obvious: > You are using a recent version of binutils (if not the most recent) !? Yes, I tried 2.15.97 and also ld.exe from 2.16.02 (I had a problem with 'make install' so I only could use ld from 2.16.02) > > I'm using the commercial version of Qt3 and am building it using > the most recent MinGW toolchain. While creating qt-mt333.dll > (or qt-mt334.dll) does indeed take both time and memory it is > manageable or so I think. So there must be a difference between qt3/commercial and our qt3/free, but I really don't know what it should be since we're using the same specs and qmake is also the same. > > So to come back to your original problem 'ld memory usage': > Basically you are looking for a solution to reduce linktime > memory consuption of the MinGW-toolchain ? Yes, I first thought loading all the object files is the problem, but then I saw that ld seems not to use more than 400MB for this and linking to import libs is (maybe) the problem. So I tried it with direct linking to win32 system dlls and got the problem with the missing '@nn'. I really couldn't link qt-dll in a acceptable time on my machine and also other users complained about this problem. Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCkECPnNKwkgf+zVMRAuCWAJ9qCYB8Z/ZQIPRmwjysDFSdADQUjACgjbrd B1R0soegdnN9bOHeia6FCWc= =73wE -----END PGP SIGNATURE----- |
From: Michael G. <mg...@te...> - 2005-05-22 08:40:04
|
Ok, I just downloaded the most recent qt3-win-3.3 snapshot (20050522) and I will give it a try in a minute or two. Anything to take care of apart from the instructions on the website ? Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Christian E. <Ch....@gm...> - 2005-05-22 09:24:24
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Gerdau schrieb: > Ok, I just downloaded the most recent qt3-win-3.3 snapshot (20050522) > and I will give it a try in a minute or two. > > Anything to take care of apart from the instructions on the > website ? No, not that I know. Thx, Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCkE+wnNKwkgf+zVMRAsK+AKCjjAovdFKLgTyIcJkOp/UWgX2IXwCbBrhd IwVU1NXf1hYkky3Df7C/VbY= =1fL4 -----END PGP SIGNATURE----- |
From: Michael G. <mg...@te...> - 2005-05-23 04:22:49
|
Meanwhile I've build the latest (i.e. 20050522) snapshot of qt3-win on my machine as described on the website. Timings are this: qt-mt3.dll 52 minutes from start uic.exe 54 minutes from start designer.exe 1 hour 20 minutes from start assistant 1 hour 30 minutes from start linguist 1 hour 33 minutes from start last example: 2 hour 28 minutes from start (examples\xml\tagreader-with-features) I'm using binutils-2.15.94-20050118-1, gcc-*-3.4.2-20040916-1 mingw-runtime-3.7, mingw-util-0.3 and w32api-3.2 Running WXP Home SP2, P4 3GHz, 2GB on a Notebook (read: relatively slow HD). During the process I had an occasional look at the TaskManager w/r to memory and swapfile usage. It didn't look out of the expected, i.e. there weren't more than a couple of 100MB. However from memory I seem to recall that earlier versions of binutils had used considerably more memory when building the commercial version of Qt and thus took much more time. I no longer recall the magnitude though. I also recall that on another machine with "only" 512MB RAM (otherwise similarly equipped) the same build took about twice as long with an earlier version of binutils. I don't have current figures because meanwhile that machine has 1GB. To sum up: Building Qt does indeed take quite some memory at linktime. binutils-2.15.94-20050118-1 is much less demanding then earlier versions but still uses _some_ memory. I have no experience with even newer versions of bintutils. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Christian E. <Ch....@gm...> - 2005-05-23 05:32:42
|
> Meanwhile I've build the latest (i.e. 20050522) snapshot of > qt3-win on my machine as described on the website. > > Timings are this: > qt-mt3.dll 52 minutes from start > uic.exe 54 minutes from start > designer.exe 1 hour 20 minutes from start > assistant 1 hour 30 minutes from start > linguist 1 hour 33 minutes from start > last example: 2 hour 28 minutes from start > (examples\xml\tagreader-with-features) > > I'm using binutils-2.15.94-20050118-1, gcc-*-3.4.2-20040916-1 > mingw-runtime-3.7, mingw-util-0.3 and w32api-3.2 > > Running WXP Home SP2, P4 3GHz, 2GB on a Notebook (read: > relatively slow HD). > > During the process I had an occasional look at the TaskManager > w/r to memory and swapfile usage. It didn't look out of the > expected, i.e. there weren't more than a couple of 100MB. > > However from memory I seem to recall that earlier versions > of binutils had used considerably more memory when building > the commercial version of Qt and thus took much more time. > I no longer recall the magnitude though. > > I also recall that on another machine with "only" 512MB RAM > (otherwise similarly equipped) the same build took about > twice as long with an earlier version of binutils. I don't > have current figures because meanwhile that machine has 1GB. > > To sum up: > Building Qt does indeed take quite some memory at linktime. > binutils-2.15.94-20050118-1 is much less demanding then earlier > versions but still uses _some_ memory. > > I have no experience with even newer versions of bintutils. Thx for your test. I think your 2GB of ram made it possible to compile qt-dll that fast. I just have 512-1024MB and ld starts swapping after a few minutes (it uses about 1.1GB of virtual memory at this point). Christian -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ |
From: Michael G. <mg...@te...> - 2005-05-23 05:49:09
|
> Thx for your test. I think your 2GB of ram made it possible to compile > qt-dll that fast. I just have 512-1024MB and ld starts swapping after a f= ew > minutes (it uses about 1.1GB of virtual memory at this point). I can imagine 512MB not being enough for building qt. 1GB definitely should be sufficient -- at least it is for the commercial version. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |