From: Ed <ej...@id...> - 2006-12-01 17:08:00
|
Howdy all! I am the maintainer of a free software package for climate scientists, called netCDF. It is a goal to produce a netCDF dll using mingw, which will work withing Microsoft (and other) windows development tools. As a start, I am trying to get the example from the FAQ working: http://www.mingw.org/mingwfaq.shtml#faq-msvcdll Unfortrunately, the example in the FAQ doesn't contain the contents of testdll.c and testdll! Here's what I have - does it look correct? testdll.h: __declspec(dllimport) int call_me(int i); testdll.c: __declspec(dllexport) int call_me(int i) { return i; } I compile these like this: $ gcc -shared -o testdll.dll testdll.c -Wl,--output-def,testdll.def,--out-implib,libtestdll.a Creating library file: libtestdll.a Then I open a visual studio DOS window and move to the directory, and issue the command: lib /machine:i386 /def:testdll.def This tells me that the library testdll.lib and object testdll.exp have been created. So far, so good. Now I open visual studio, and start a console based C++ app. The code looks like this: #include "stdafx.h" #include <testdll.h> #using <mscorlib.dll> using namespace System; int _tmain() { int i; i = call_me(42); printf("howdy - %d\n", i); return 0; } I copy the testdll.dll file to the same directory as the visual studio project. (I also tried copying to \windows\system32). I told the C++ preprocessor to look in the directory with testdll.h, and I told the C++ linker to look in the directory with the netcdf.lib file. I also told the linker to include testdll.lib. My command line looks like this: Creating temporary file "c:\cygwin\home\ed\ming\ming1\Debug\RSP00000F.rsp" with contents [ /OUT:"C:\cygwin\home\ed\ming\ming1\Debug\ming1.exe" /INCREMENTAL /NOLOGO /LIBPATH:"C:\cygwin\home\ed\ming" /DEBUG /ASSEMBLYDEBUG /PDB:"C:\cygwin\home\ed\ming\ming1\Debug/ming1.pdb" /FIXED:No testdll.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib .\debug\ming1.obj .\debug\AssemblyInfo.obj .\debug\stdafx.obj .\debug\app.res ] Creating command line "link.exe @c:\cygwin\home\ed\ming\ming1\Debug\RSP00000F.rsp" (What use is the netcdf.exp file?) However, the linker still can't resolve the reference to function call_me(): C:\cygwin\home\ed\ming\ming1\Debug\ming1.exe : fatal error LNK1120: 1 unresolved externals Has anyone gotten this example to work? If so, could you send me your testdll.c, testdll.h, and command line from a successful build with visual studio? Thanks! Ed |
From: Brian D. <br...@de...> - 2006-12-01 17:46:29
|
Ed wrote: > __declspec(dllimport) int call_me(int i); > [...] > Now I open visual studio, and start a console based C++ app. The code > [...] > However, the linker still can't resolve the reference to function call_me(): > > C:\cygwin\home\ed\ming\ming1\Debug\ming1.exe : fatal error LNK1120: 1 unresolved externals You're trying to call a C function from C++, but your function has not been declared 'extern "C"'. This has nothing to do with the fact that it's MinGW and MSVC++, it's all due to C/C++ semantics. The example assumes that both modules are C. This is why almost all public headers of C modules have something like: #ifdef __cplusplus extern "C" { #endif /* body of header */ #ifdef __cplusplus } #endif Brian |
From: Ed <ej...@id...> - 2006-12-01 19:43:37
|
Brian Dessent <br...@de...> writes: > You're trying to call a C function from C++, but your function has not > been declared 'extern "C"'. This has nothing to do with the fact that > it's MinGW and MSVC++, it's all due to C/C++ semantics. The example > assumes that both modules are C. Right you are Brian! Thanks, now the dll works as expected from Visual Studio. The DLL menace was at an end. The quest for the Holy Grail could continue... Here's what works for me: testdll.h: #ifdef __cplusplus extern "C" { #endif __declspec(dllimport) int call_me(int i); #ifdef __cplusplus } #endif testdll.c: __declspec(dllexport) int call_me(int i) { return i-5; } Thanks Brian! Ed |
From: Roger K. W. <ROG...@sa...> - 2006-12-01 18:34:42
|
FWIW I use netCDF in conjunction with GMT. For several years I have built "libnetcdf.dll" (now at version 3.6.0) using MinGW. Let me know if anything I might have (build script, binary, etc) might help and I will send it along. Ed wrote: > Howdy all! > > I am the maintainer of a free software package for climate scientists, > called netCDF. It is a goal to produce a netCDF dll using mingw, which > will work withing Microsoft (and other) windows development tools. > > As a start, I am trying to get the example from the FAQ working: > http://www.mingw.org/mingwfaq.shtml#faq-msvcdll > > Unfortrunately, the example in the FAQ doesn't contain the contents of > testdll.c and testdll! > > Here's what I have - does it look correct? > > testdll.h: > > __declspec(dllimport) int call_me(int i); > > testdll.c: > > __declspec(dllexport) int > call_me(int i) > { > return i; > } > > I compile these like this: > > $ gcc -shared -o testdll.dll testdll.c -Wl,--output-def,testdll.def,--out-implib,libtestdll.a > Creating library file: libtestdll.a > > Then I open a visual studio DOS window and move to the directory, and > issue the command: > > lib /machine:i386 /def:testdll.def > > This tells me that the library testdll.lib and object testdll.exp have > been created. > > So far, so good. > > Now I open visual studio, and start a console based C++ app. The code > looks like this: > > > #include "stdafx.h" > #include <testdll.h> > #using <mscorlib.dll> > > using namespace System; > > int _tmain() > { > int i; > > i = call_me(42); > printf("howdy - %d\n", i); > > return 0; > } > > I copy the testdll.dll file to the same directory as the visual studio > project. (I also tried copying to \windows\system32). I told the C++ > preprocessor to look in the directory with testdll.h, and I told the > C++ linker to look in the directory with the netcdf.lib file. I also > told the linker to include testdll.lib. > > My command line looks like this: > > Creating temporary file "c:\cygwin\home\ed\ming\ming1\Debug\RSP00000F.rsp" with contents > [ > /OUT:"C:\cygwin\home\ed\ming\ming1\Debug\ming1.exe" /INCREMENTAL /NOLOGO /LIBPATH:"C:\cygwin\home\ed\ming" /DEBUG /ASSEMBLYDEBUG /PDB:"C:\cygwin\home\ed\ming\ming1\Debug/ming1.pdb" /FIXED:No testdll.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib > .\debug\ming1.obj > .\debug\AssemblyInfo.obj > .\debug\stdafx.obj > .\debug\app.res > ] > Creating command line "link.exe @c:\cygwin\home\ed\ming\ming1\Debug\RSP00000F.rsp" > > (What use is the netcdf.exp file?) > > However, the linker still can't resolve the reference to function call_me(): > > C:\cygwin\home\ed\ming\ming1\Debug\ming1.exe : fatal error LNK1120: 1 unresolved externals > > Has anyone gotten this example to work? If so, could you send me your > testdll.c, testdll.h, and command line from a successful build with > visual studio? > > Thanks! > > Ed > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > > -- Roger Wells, P.E. SAIC 221 Third St Newport, RI 02840 401-847-4210 (voice) 401-849-1585 (fax) rog...@sa... |
From: Ed <ej...@id...> - 2006-12-01 19:25:33
|
"Roger K. Wells" <ROG...@sa...> writes: > FWIW > > I use netCDF in conjunction with GMT. For several years I have built > "libnetcdf.dll" (now at version 3.6.0) using MinGW. > Let me know if anything I might have (build script, binary, etc) might > help and I will send it along. > Yeehaa! I love the netCDF community! I have been having a very hard time with this. One wonderful thing you could do would be to get the daily netCDF distribution, and try and build it under mingw, and tell me what I am doing wrong. The distribution can be found here: ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-daily.tar.gz Please also do send me your build script, or whatever else you have. The intention is to make this a permanent netCDF port. That is, to add MinGW/DLL to our list of supported platforms permanently. Thanks, Ed |
From: Ed <ej...@id...> - 2006-12-02 14:16:58
|
"Roger K. Wells" <ROG...@sa...> writes: > FWIW > > I use netCDF in conjunction with GMT. For several years I have built > "libnetcdf.dll" (now at version 3.6.0) using MinGW. > Let me know if anything I might have (build script, binary, etc) might > help and I will send it along. > Howdy Roger! I see you work for SAIC. I believe I worked with a lot of SAIC people at Goddard some years ago! It's an invariable rule of software development that as soon as you ask someone for help, you see the answer immediately. The case of the netCDF DLL is no exception. As soon as I woke up this morning I tried it all again and managed to get a netCDF dll which works in visual studio. Which is nice. I do have some questions though, which perhaps you, or some other kind windows programmer, can answer: 1 - Any clue why libtool gives me a DLL named libnetcdf-0.dll instead of libnetcdf.dll? I am just renaming this to libnetcdf.dll anyway. 2 - Shouldn't the name be netcdf.dll anyway? That is, why do we have the "lib" in front? I have it because libtool puts it there, but if I have to rename it anyway, I don't see any reason not to name it properly. All previous netCDF dll releases have been called netcdf.dll. 3 - When I run "make check" of netCDF, under MinGW, it fails with a windows message box telling me that libnetcdf.dll could not be found. I copied libnetcdf.dll to /windows/system32, and tried again, and it worked. Fine, but how am I supposed to handle this as a distribution? Install the dll before running the tests on the user machine? That seems crazy! 4 - What files should be included in the binary distribution to the netcdf developer? Obviously netcdf.h, netcdf.dll, and netcdf.lib. Any other ones? When installed, netcdf.dll should go in /windows/system32, but where should the others go? Any answers would be most welcome. Almost all netCDF development and use takes place on Unix systems, so that is where most of my effort goes. It is nice to have Ming to use the same build system to build the DLLs! Now I've just got to figure out how to get the fortran wrappers working on windows... Thanks, Ed Hartnett Unidata |
From: Earnie B. <ea...@us...> - 2006-12-02 14:37:28
|
Quoting Ed <ej...@id...>: > 1 - Any clue why libtool gives me a DLL named libnetcdf-0.dll instead > of libnetcdf.dll? I am just renaming this to libnetcdf.dll anyway. > Libtool smartly versions the libraries so that when you upgrade all of the binaries don't need to be upgraded at the same time. See the libtool documentation and lists. > 2 - Shouldn't the name be netcdf.dll anyway? No, libnetcdf.dll will be found by GCC as the library to link with in it's search for libraries. The import library isn't needed if the dll is used instead. This matches the UNIX scenarios. Again see the libtool documentation and lists. > > 3 - When I run "make check" of netCDF, under MinGW, it fails with a > windows message box telling me that libnetcdf.dll could not be > found. I copied libnetcdf.dll to /windows/system32, and tried again, > and it worked. Fine, but how am I supposed to handle this as a > distribution? Install the dll before running the tests on the user > machine? That seems crazy! > You need to modify the tests Makefile to add a path to where the built library lives to PATH or copy the dll to the test directory. > 4 - What files should be included in the binary distribution to the > netcdf developer? Obviously netcdf.h, netcdf.dll, and netcdf.lib. Any > other ones? When installed, netcdf.dll should go in /windows/system32, > but where should the others go? > What is included with a UNIX build? It sounds reasonable that netcdf.h, libnetcdf.dll and netcdf.lib are what is included. > Any answers would be most welcome. > > Almost all netCDF development and use takes place on Unix systems, so > that is where most of my effort goes. It is nice to have Ming to use > the same build system to build the DLLs! > You stated that you were using VStudio; have you tried MSYS which gives you a minimal UNIX shell with a mingw32 build environment? Then you execute configure --prefix=`cd /mingw && pwd -W` to build using GCC. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. -- ****************************************************************************** * The user of this server has agreed to allow the use of a trailer in the * * mail that he sends for advertising purposes. This advertisment is added * * by the server and is not in the control of the user of our services. * ****************************************************************************** Save on your shoes, socks and other needs: http://give-me-an-offer.com/store/shoes Save on your baby gift needs: http://give-me-an-offer.com/offers/products/baby |
From: Ed <ej...@id...> - 2006-12-03 11:30:35
|
Earnie Boyd <ea...@us...> writes: > Quoting Ed <ej...@id...>: > > > 1 - Any clue why libtool gives me a DLL named libnetcdf-0.dll instead > > of libnetcdf.dll? I am just renaming this to libnetcdf.dll anyway. > > > > Libtool smartly versions the libraries so that when you upgrade all of > the binaries don't need to be upgraded at the same time. See the > libtool documentation and lists. The libtool documentation mentions little about dlls, and, as far as I can find, make no mention of why libtool is giving my dlls this name. A search of the libtool mailing list archives has not turned up any helpful answer either. So I am still confused about why the "-O" is added to this library name. I don't understand what you mean about all the binraries being upgraded at the same time. Surely that's what I want when upgrading? > > > 2 - Shouldn't the name be netcdf.dll anyway? > > No, libnetcdf.dll will be found by GCC as the library to link with in > it's search for libraries. The import library isn't needed if the dll > is used instead. This matches the UNIX scenarios. Again see the > libtool documentation and lists. Ummm, wouldn't gcc want to use libnetcdf.a? Actually I don't understand why MinGW is using the DLL. How come it doesn't use libnetcdf.a, which also is produced, instead of the DLL? The unix side doesn't use the export library either, does it? I don't remember ever using a *.lib file in unix, just the .h and the .a. Or have I just been missing something that's going on in the background? When I look at how the test program is compiled, I see that it *is* using the .lib file. I am investigating further... If you can refer to a specific place in the docs or mailing lists, that would be more helpful. Nothing is jumping out at me. I already checked these sources before posting, and checking again now I still am not finding any answers there. Of course, there is a lot of material, and perhaps I am looking in the wrong places. Certainly I am willing to believe that all of this is documented *somewhere*. ;-) But where? As for this DLL name, my understanding is that I *need* to call it netcdf.dll, because that is what previous versions (built with visual studio) have been called. In order for user programs to get the latest version of the DLL, it has to have the same name, correct? Also, if I changed the name, all users would have to change their program configurations to use the new versions. Not good. > > 3 - When I run "make check" of netCDF, under MinGW, it fails with a > > windows message box telling me that libnetcdf.dll could not be > > found. I copied libnetcdf.dll to /windows/system32, and tried again, > > and it worked. Fine, but how am I supposed to handle this as a > > distribution? Install the dll before running the tests on the user > > machine? That seems crazy! > > > > You need to modify the tests Makefile to add a path to where the built > library lives to PATH or copy the dll to the test directory. OK, thanks, the PATH idea seems like the way to proceed. However I also realize that, if I want to be able to build and test a DLL on MinGW, I will also need to have my makefile call the MS "lib" program to make the MS export library from the .def file... > > 4 - What files should be included in the binary distribution to the > > netcdf developer? Obviously netcdf.h, netcdf.dll, and netcdf.lib. Any > > other ones? When installed, netcdf.dll should go in /windows/system32, > > but where should the others go? > > > > What is included with a UNIX build? It sounds reasonable that > netcdf.h, libnetcdf.dll and netcdf.lib are what is included. There is no .lib file in Unix distributions, just the .h and the .a files. > You stated that you were using VStudio; have you tried MSYS which gives > you a minimal UNIX shell with a mingw32 build environment? Then you > execute configure --prefix=`cd /mingw && pwd -W` to build using GCC. Yes, I am actually using MSYS/MinGW to build the DLL; I'm just testing it in visual studio. That is, I build the dll with MinGW, use MS's tool to generate the .lib file from the .def file that MinGW has generated, and the use visual studio to write a console app which uses the DLL, to make sure I got something that Windows programmers can use in visual studio. There are also a bunch of tests with the build, which are not run in visual studio, but are run when I do "make check" from MSYS. So I need it to work both from the MSYS command line and from within visual studio. Thanks for all the answers! Ed Hartnett |
From: Ed <ej...@id...> - 2006-12-03 13:04:53
|
"Roger K. Wells" <ROG...@sa...> writes: > FWIW > > I use netCDF in conjunction with GMT. For several years I have built > "libnetcdf.dll" (now at version 3.6.0) using MinGW. > Let me know if anything I might have (build script, binary, etc) might > help and I will send it along. > Roger, I can now produce the C DLL under MinGW, but I have to fire up the Visual Studio DOS shell to run the lib command to create the .lib file. Have you ever succeeded in running this lib.exe command from the MSYS environment? If so, I can have the makefile do this part too. As it is, I just get a message box telling me that a dll is missing from my path when I try and run lib.exe from MSYS. Thanks, Ed |
From: Earnie B. <ea...@us...> - 2006-12-03 14:06:16
|
Quoting Ed <ej...@id...>: > "Roger K. Wells" <ROG...@sa...> writes: > >> FWIW >> >> I use netCDF in conjunction with GMT. For several years I have built >> "libnetcdf.dll" (now at version 3.6.0) using MinGW. >> Let me know if anything I might have (build script, binary, etc) might >> help and I will send it along. >> > > Roger, > > I can now produce the C DLL under MinGW, but I have to fire up the > Visual Studio DOS shell to run the lib command to create the .lib > file. > Have you tried ``cp libnetcdf.a netcdf.lib''? Do note that gcc/binutils searches for libnetcdf.dll, libnetcdf.dll.a, libnetcdf.a and netcdf.lib in its searches for the library. > Have you ever succeeded in running this lib.exe command from the MSYS > environment? If so, I can have the makefile do this part too. > I've not tried it. Switches in the form of /a need to be doubly slashed //a. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. -- ****************************************************************************** * The user of this server has agreed to allow the use of a trailer in the * * mail that he sends for advertising purposes. This advertisment is added * * by the server and is not in the control of the user of our services. * ****************************************************************************** Save on your shoes, socks and other needs: http://give-me-an-offer.com/store/shoes Save on your baby gift needs: http://give-me-an-offer.com/offers/products/baby |
From: Ed <ej...@id...> - 2006-12-04 17:07:12
|
Earnie Boyd <ea...@us...> writes: > Quoting Ed <ej...@id...>: > > > "Roger K. Wells" <ROG...@sa...> writes: > > > >> FWIW > >> > >> I use netCDF in conjunction with GMT. For several years I have built > >> "libnetcdf.dll" (now at version 3.6.0) using MinGW. > >> Let me know if anything I might have (build script, binary, etc) might > >> help and I will send it along. > >> > > > > Roger, > > > > I can now produce the C DLL under MinGW, but I have to fire up the > > Visual Studio DOS shell to run the lib command to create the .lib > > file. > > > > Have you tried ``cp libnetcdf.a netcdf.lib''? Do note that > gcc/binutils searches for libnetcdf.dll, libnetcdf.dll.a, libnetcdf.a > and netcdf.lib in its searches for the library. You amaze me! Yet the gcc manual does not mention this. Is it a special MinGW thing? The gcc manual says: The linker searches a standard list of directories for the library, which is actually a file named `libLIBRARY.a'. The linker then uses this file as if it had been specified precisely by name. and later: The only difference between using an `-l' option and specifying a file name is that `-l' surrounds LIBRARY with `lib' and `.a' and searches several directories. No mention of trying without the "lib"! > > > Have you ever succeeded in running this lib.exe command from the MSYS > > environment? If so, I can have the makefile do this part too. > > > > I've not tried it. Switches in the form of /a need to be doubly slashed //a. > Thanks for that tip, I was thinking there was going to be some trouble about the slashes that DOS uses to pass options to commands! Thanks, Ed |
From: Bob R. <bob...@co...> - 2006-12-03 13:33:14
|
On Sun, Dec 03, 2006 at 06:04:18AM -0700, Ed wrote: > "Roger K. Wells" <ROG...@sa...> writes: > > > FWIW > > > > I use netCDF in conjunction with GMT. For several years I have built > > "libnetcdf.dll" (now at version 3.6.0) using MinGW. > > Let me know if anything I might have (build script, binary, etc) might > > help and I will send it along. > > > > Roger, > > I can now produce the C DLL under MinGW, but I have to fire up the > Visual Studio DOS shell to run the lib command to create the .lib > file. > > Have you ever succeeded in running this lib.exe command from the MSYS > environment? If so, I can have the makefile do this part too. > > As it is, I just get a message box telling me that a dll is missing > from my path when I try and run lib.exe from MSYS. Hi Ed, I haven't been following to closely, but have you seen this, http://www.mingw.org/MinGWiki/index.php/MSVC-MinGW-DLL Bob Rossi |
From: Ed <ej...@id...> - 2006-12-04 01:59:58
|
Bob Rossi <bob...@co...> writes: > On Sun, Dec 03, 2006 at 06:04:18AM -0700, Ed wrote: > > "Roger K. Wells" <ROG...@sa...> writes: > > > > > FWIW > > > > > > I use netCDF in conjunction with GMT. For several years I have built > > > "libnetcdf.dll" (now at version 3.6.0) using MinGW. > > > Let me know if anything I might have (build script, binary, etc) might > > > help and I will send it along. > > > > > > > Roger, > > > > I can now produce the C DLL under MinGW, but I have to fire up the > > Visual Studio DOS shell to run the lib command to create the .lib > > file. > > > > Have you ever succeeded in running this lib.exe command from the MSYS > > environment? If so, I can have the makefile do this part too. > > > > As it is, I just get a message box telling me that a dll is missing > > from my path when I try and run lib.exe from MSYS. > > Hi Ed, > > I haven't been following to closely, but have you seen this, > http://www.mingw.org/MinGWiki/index.php/MSVC-MinGW-DLL > > Bob Rossi > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users Yes, thanks, I've read that closely... Thanks, Ed |
From: Tor L. <tm...@ik...> - 2006-12-04 09:29:13
|
Ed writes: > The libtool documentation mentions little about dlls, and, as far as I > can find, make no mention of why libtool is giving my dlls this > name. A search of the libtool mailing list archives has not turned up > any helpful answer either. So I am still confused about why the "-O" > is added to this library name. For the same reason that it would call it libnetcdf.so.0 on Linux. Google for the keywords libtool, versioning and dll. > The unix side doesn't use the export library either, does it? There are no separate export libraries on Unix systems, as far as I know. Certainly not on ELF-based systems (Linux, Solaris, etc) or HP-UX at least. > As for this DLL name, my understanding is that I *need* to call it > netcdf.dll, because that is what previous versions (built with visual > studio) have been called. Then you should try to use the libtool options --avoid-version and/or --module. If nothing helps, you might need to drop libtool altogether and just write the linking command explicitly into the makefile. > In order for user programs to get the latest version of the DLL, it > has to have the same name, correct? Are the versions you talk about here backward compatible? (Only new entry points are added, none are removed, and the API+ABI of the existing ones don't change?) In that case, the DLL name is not supposed to change. --tml |
From: Greg C. <chi...@co...> - 2006-12-04 17:27:13
|
On 2006-12-4 17:06 UTC, Ed wrote: > Earnie Boyd <ea...@us...> writes: > >> Have you tried ``cp libnetcdf.a netcdf.lib''? Do note that >> gcc/binutils searches for libnetcdf.dll, libnetcdf.dll.a, libnetcdf.a >> and netcdf.lib in its searches for the library. > > Yet the gcc manual does not mention this. Is it a special MinGW thing? http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html Look for the part that begins: | For instance, when ld is called with the argument -lxxx it will attempt to find |
From: Ed <ej...@id...> - 2006-12-05 11:46:52
|
Greg Chicares <chi...@co...> writes: > On 2006-12-4 17:06 UTC, Ed wrote: > > Earnie Boyd <ea...@us...> writes: > > > >> Have you tried ``cp libnetcdf.a netcdf.lib''? Do note that > >> gcc/binutils searches for libnetcdf.dll, libnetcdf.dll.a, libnetcdf.a > >> and netcdf.lib in its searches for the library. > > > > Yet the gcc manual does not mention this. Is it a special MinGW thing? > > http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html > > Look for the part that begins: > | For instance, when ld is called with the argument -lxxx it will > attempt to find Thanks, that's a great reference and I have been reading it closely. To answer my own question, the doc says that on mingw and cygwin, ld is searching for libraries in the following way: "Linking directly to a dll uses no extra command-line switches other than -L and -l, because ld already searches for a number of names to match each library. All that is needed from the developer's perspective is an understanding of this search, in order to force ld to select the dll instead of an import library. "For instance, when ld is called with the argument -lxxx it will attempt to find, in the first directory of its search path, libxxx.dll.a xxx.dll.a libxxx.a cygxxx.dll (*) libxxx.dll xxx.dll "before moving on to the next directory in the search path." |
From: Ed <ej...@id...> - 2006-12-04 18:32:42
|
Tor Lillqvist <tm...@ik...> writes: > Ed writes: > > The libtool documentation mentions little about dlls, and, as far as I > > can find, make no mention of why libtool is giving my dlls this > > name. A search of the libtool mailing list archives has not turned up > > any helpful answer either. So I am still confused about why the "-O" > > is added to this library name. > > For the same reason that it would call it libnetcdf.so.0 on > Linux. Google for the keywords libtool, versioning and dll. Thanks, now I get it. But my understanding is that version information is stored inside DLLs in the MS world, not in the file name of the DLL. Won't putting the version in the file name break from any MS development platform? That is, Visual Studio will look for netcdf.dll, not netcdf-<HIGHEST_VERSION_NUMBER>.dll. Consequently, when upgrading the dll, any version information in the DLL filename will be misunderstood by the OS, so that the newer DLLs will not be used. Or am I missing something? > > As for this DLL name, my understanding is that I *need* to call it > > netcdf.dll, because that is what previous versions (built with visual > > studio) have been called. > > Then you should try to use the libtool options --avoid-version and/or > --module. If nothing helps, you might need to drop libtool altogether > and just write the linking command explicitly into the makefile. Heaven forbid that I should sink to such a level as to sully my hands with creating a link command! ;-) I have used -avoid-version (one hyphen) to stop libtool from putting the version number in the dll name. Thanks! > > In order for user programs to get the latest version of the DLL, it > > has to have the same name, correct? > > Are the versions you talk about here backward compatible? (Only new > entry points are added, none are removed, and the API+ABI of the > existing ones don't change?) In that case, the DLL name is not > supposed to change. Yes, that is my understanding. Ed |
From: Greg C. <chi...@co...> - 2006-12-04 18:49:06
|
On 2006-12-4 18:32 UTC, Ed wrote: > Tor Lillqvist <tm...@ik...> writes: > >> Ed writes: >> > The libtool documentation mentions little about dlls, and, as far as I >> > can find, make no mention of why libtool is giving my dlls this >> > name. A search of the libtool mailing list archives has not turned up >> > any helpful answer either. So I am still confused about why the "-O" >> > is added to this library name. >> >> For the same reason that it would call it libnetcdf.so.0 on >> Linux. Google for the keywords libtool, versioning and dll. > > Thanks, now I get it. But my understanding is that version information > is stored inside DLLs in the MS world, not in the file name of the > DLL. Here's one example where version suffixes are added: C:/WINDOWS/SYSTEM32[0]$ls MSVC* MSVCIRT.DLL MSVCP60.DLL MSVCR70.DLL MSVCRT20.DLL MSVCP50.DLL MSVCP70.DLL MSVCRT.DLL > Won't putting the version in the file name break from any MS > development platform? That is, Visual Studio will look for netcdf.dll, > not netcdf-<HIGHEST_VERSION_NUMBER>.dll. Consequently, when upgrading > the dll, any version information in the DLL filename will be > misunderstood by the OS, so that the newer DLLs will not be used. I'd just distribute the right dll version with my program binary, and install both to the same directory (not putting the dll in some system directory). Then everything should just work, with no version information in the dll, as far as I know (but I don't use ms tools). |
From: Tor L. <tm...@ik...> - 2006-12-04 19:02:46
|
Ed writes: > Thanks, now I get it. But my understanding is that version information > is stored inside DLLs in the MS world, Well, that's a different kind of version... > not in the file name of the DLL. As Greg replied, Microsoft has used version numbers in the name of DLLs for the C and C++ runtime libraries bundled with its compilers, for example. But anyway, the number that libtool uses when constructing DLL names is not directly a version number. It's the result of more complex calculation involving concepts such as "interface (version) number" and "interface age". > Won't putting the version in the file name break from any MS > development platform? That is, Visual Studio will look for netcdf.dll, > not netcdf-<HIGHEST_VERSION_NUMBER>.dll. The number that libtool appends is not "HIGHEST_VERSION_NUMBER". It is, roughly speaking, the oldest version number with which the DLL is still backward compatible. The opposite, using the same name for DLLs that are not binary compatible would be asking for trouble. --tml |
From: Teus B. <te...@te...> - 2006-12-05 03:58:04
|
I'd like to ask something about how to suppress the DOS box that appears while using commands like "mkdir". My Gtk2 application suppresses its own DOS box by using the -mwindows flag during the linking process. That works fine. But this application at times calls some Linux commands, such as "mkdir", rmdir", "rm -rf", etc. Each of them, when called, bring up a DOS box during the time that command runs. These DOS boxes appear as black flashes on the screen, on top of the GUI, and look a bit untidy. Is there any way to suppress that? Thanks, Teus Benschop |
From: Greg C. <chi...@co...> - 2006-12-05 04:23:21
|
On 2006-12-5 3:57 UTC, Teus Benschop wrote: > I'd like to ask something about how to suppress the DOS box that appears > while using commands like "mkdir". > > My Gtk2 application suppresses its own DOS box by using the -mwindows > flag during the linking process. That works fine. But this application > at times calls some Linux commands, such as "mkdir", rmdir", "rm -rf", > etc. Each of them, when called, bring up a DOS box during the time that > command runs. These DOS boxes appear as black flashes on the screen, on > top of the GUI, and look a bit untidy. > > Is there any way to suppress that? How are you invoking those programs? If you're using CreateProcess(), then try googling for STARTF_USESHOWWINDOW |
From: Teus B. <te...@te...> - 2006-12-05 04:39:27
|
Greg Chicares wrote: > On 2006-12-5 3:57 UTC, Teus Benschop wrote: > >> I'd like to ask something about how to suppress the DOS box that appears >> while using commands like "mkdir". >> >> My Gtk2 application suppresses its own DOS box by using the -mwindows >> flag during the linking process. That works fine. But this application >> at times calls some Linux commands, such as "mkdir", rmdir", "rm -rf", >> etc. Each of them, when called, bring up a DOS box during the time that >> command runs. These DOS boxes appear as black flashes on the screen, on >> top of the GUI, and look a bit untidy. >> >> Is there any way to suppress that? >> > > How are you invoking those programs? > > If you're using CreateProcess(), then try googling for > STARTF_USESHOWWINDOW > Thanks, will look into that. But at present they are invoked using Glib's function g_spawn_async_with_pipes (), and g_spawn_sync (). Teus. |
From: Earnie B. <ea...@us...> - 2006-12-05 12:35:39
|
Quoting Teus Benschop <te...@te...>: > Thanks, will look into that. But at present they are invoked using > Glib's function g_spawn_async_with_pipes (), and g_spawn_sync (). > I've read Tor's comment and your reply and agree with Tor; however for the sake of answering the question posed, PIPES work on console handles so a console is created to support the PIPE from your windows program. You'll need to modify the functions to suppress the console window that is open at the request of your pipe function. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. -- ****************************************************************************** * The user of this server has agreed to allow the use of a trailer in the * * mail that he sends for advertising purposes. This advertisment is added * * by the server and is not in the control of the user of our services. * ****************************************************************************** Save on your shoes, socks and other needs: http://give-me-an-offer.com/store/shoes Save on your baby gift needs: http://give-me-an-offer.com/offers/products/baby Playstation 3 Auctions http://give-me-an-offer.com |
From: Ed <ej...@id...> - 2006-12-05 11:51:22
|
Greg Chicares <chi...@co...> writes: > > Thanks, now I get it. But my understanding is that version information > > is stored inside DLLs in the MS world, not in the file name of the > > DLL. > > Here's one example where version suffixes are added: > > C:/WINDOWS/SYSTEM32[0]$ls MSVC* > MSVCIRT.DLL MSVCP60.DLL MSVCR70.DLL MSVCRT20.DLL > MSVCP50.DLL MSVCP70.DLL MSVCRT.DLL Yes, but this is not the same as the version info in the unix library name. For example, an application would not be able to select the correct DLL based on these versions - the version number is just part of the name of the DLL, not treated in any special way by the loader, as it is on Unix systems. > > > Won't putting the version in the file name break from any MS > > development platform? That is, Visual Studio will look for netcdf.dll, > > not netcdf-<HIGHEST_VERSION_NUMBER>.dll. Consequently, when upgrading > > the dll, any version information in the DLL filename will be > > misunderstood by the OS, so that the newer DLLs will not be used. > > I'd just distribute the right dll version with my program binary, > and install both to the same directory (not putting the dll in > some system directory). Then everything should just work, with no > version information in the dll, as far as I know (but I don't use > ms tools). > I am not distributing the program, just the library. That is, we have a freeware atmospheric science library, netCDF, and it is distributed on Unix system. There is also a windows DLL port. The users out there in the big wide world are the ones with the applications. Thanks! Ed |
From: Earnie B. <ea...@us...> - 2006-12-05 12:51:37
|
Quoting Ed <ej...@id...>: > > I am not distributing the program, just the library. > Which makes it even more important that you version the name of the dll to identify the ABI/API as Tor has already mentioned. Libtool is developed by those who actually know how to provide libraries. There are reasons it versions the files. If I were you I would take the advice of many years of library creators and version the file name and quit arguing about the semantics of where the version is stored. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. -- ****************************************************************************** * The user of this server has agreed to allow the use of a trailer in the * * mail that he sends for advertising purposes. This advertisment is added * * by the server and is not in the control of the user of our services. * ****************************************************************************** Save on your shoes, socks and other needs: http://give-me-an-offer.com/store/shoes Save on your baby gift needs: http://give-me-an-offer.com/offers/products/baby Playstation 3 Auctions http://give-me-an-offer.com |