From: Eric N. <er...@di...> - 2009-06-07 19:19:39
|
Hello, I am a bit new to the MinGW world and have done a bit of tinkering with it to have the development libraries for openldap and openssl installed. My latest library to try and get loaded is libcgi: http://libcgi.sourceforge.net/ Unfortunately it does not have a MinGW option in it's configuration script. This is an extremely simple library with no dependencies. I was wondering if anyone could give me some pointers on how to get this compiled and generating dll's instead of .so files. My hope is to port some of my perl compiled code to C using MinGW. Many thanks! |
From: Eric N. <er...@di...> - 2009-06-08 01:05:22
|
On Sun, June 7, 2009 3:01 pm, Eric Nichols wrote: > Hello, > I am a bit new to the MinGW world and have done a bit of tinkering with it to > have the development libraries for openldap and openssl installed. > > My latest library to try and get loaded is libcgi: > http://libcgi.sourceforge.net/ > > Unfortunately it does not have a MinGW option in it's configuration script. > This is an extremely simple library with no dependencies. I was wondering if > anyone could give me some pointers on how to get this compiled and generating > dll's instead of .so files. > > My hope is to port some of my perl compiled code to C using MinGW. > Many thanks! With a bit of humble pie I've figured out what went right and wrong. Good news libcgi builds and installs without modification from the msys environment: ./configure --prefix=/mingw Bad news. MinGW's gcc specification of libraries is VERY specific. A clue on this can be found in the docs: http://www.mingw.org/wiki/Specify_the_libraries_for_the_linker_to_use So when building the example programs the Makefile had: $(CC) $(FLAGS) -lcgi gbook.c -o @(CGIBIN)/gbook.cgi In MinGW you have to specify the library LAST: $(CC) $(FLAGS) gbook.c -o @(CGIBIN)/gbook.cgi -lcgi Obviously this is a know issue (it's documented). Is there any reason why this is the case? For the uninitiated (like me) this is a speed bump to porting code that probably shouldn't be? Insights are always welcome. Now if there were a simple windows program that can tell you what DLL's a program requires..... Thanks Eric |
From: Greg C. <gch...@sb...> - 2009-06-08 02:16:48
|
On 2009-06-08 00:28Z, Eric Nichols wrote: > > Bad news. MinGW's gcc specification of libraries is VERY specific. A clue on > this can be found in the docs: > http://www.mingw.org/wiki/Specify_the_libraries_for_the_linker_to_use > > So when building the example programs the Makefile had: > $(CC) $(FLAGS) -lcgi gbook.c -o @(CGIBIN)/gbook.cgi > > In MinGW you have to specify the library LAST: > $(CC) $(FLAGS) gbook.c -o @(CGIBIN)/gbook.cgi -lcgi > > Obviously this is a know issue (it's documented). Is there any reason why > this is the case? For the uninitiated (like me) this is a speed bump to > porting code that probably shouldn't be? The only defect is in the makefile. See this GNU/Linux manpage: http://linux.die.net/man/1/ld | | -larchive [...] | The linker will search an archive only once, at the location where | it is specified on the command line. If the archive defines a symbol | which was undefined in some object which appeared before the archive | on the command line, the linker will include the appropriate file(s) | from the archive. However, an undefined symbol in an object appearing | later on the command line will not cause the linker to search the | archive again. As this article: http://article.gmane.org/gmane.os.cygwin/89771 explains, a badly-ordered link command might work on ELF with shared libraries--but fail on ELF with static libraries, and on PE platforms whether static or shared. > Now if there were a simple windows program that can tell you what DLL's a > program requires..... objdump -p my_dll_or_exe | grep "DLL Name" |
From: Keith M. <kei...@us...> - 2009-06-08 17:39:24
|
On Monday 08 June 2009 01:28:18 Eric Nichols wrote: > Bad news. MinGW's gcc specification of libraries is VERY > specific. A clue on this can be found in the docs: > http://www.mingw.org/wiki/Specify_the_libraries_for_the_linker_to_use And that page provides information which is generic to the GNU linker. WRT the placement of library specifications on the link command line, it applies to *any* platform which uses this linker, and is in no way MinGW specific; (the association of -lname with the MS compatible alternative name.lib convention is the only exception; it applies for MinGW and Cygwin, but not for *nix platforms). > So when building the example programs the Makefile had: > $(CC) $(FLAGS) -lcgi gbook.c -o @(CGIBIN)/gbook.cgi Well, this is just plain invalid: nothing to do with MinGW; it is *wrong* on *every* platform using the GNU linker. OTOH... > In MinGW you have to specify the library LAST: > $(CC) $(FLAGS) gbook.c -o @(CGIBIN)/gbook.cgi -lcgi ...this is correct, (except that it should surely be $(CGIBIN)/... rather than @(CGIBIN)/...), not just for MinGW, but on *every* GNU or generic UNIX platform. > Obviously this is a know issue (it's documented). Yes, and it's documented in the *generic* GCC and GNU binutils manuals, as applicable to *every* supported platform: http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options http://sourceware.org/binutils/docs/ld/Options.html#index-archive-files_002c-from-cmd-line-52 (latter equivalent to http://tinyurl.com/nrkahr in case of wrapping). > Is there any reason why this is the case? Yes; because this is how it has always been, on UNIX systems in general, from time immemorial, (i.e. since the birth of UNIX). > For the uninitiated (like me) this is a speed bump to porting code > that probably shouldn't be? No, it shouldn't be. However, I do wish that the uninitiated (like you) would resist the temptation to immediately point the finger of blame at MinGW; rather first check your own understanding of the facts, (by searching list archives; I've lost count of the number of times this has been erroneously reported, even quite recently). Only when you are sure of your ground, then go shout at all those careless developers who write their Makefiles with invalid linking command syntax, (or maybe, the developers of those ELF linkers, who carelessly let them get away with writing those invalid commands in the first instance). Better yet, just quietly point those careless developers at the appropriate documentation, and send them patches to correct their defective Makefiles. This is *not* a MinGW bug! Please review the additions I've made today, to the FAQ page you originally cited: http://tinyurl.com/m8ddzz -- Regards, Keith. |
From: Eric N. <er...@di...> - 2009-06-09 23:28:25
|
Many thanks to both Greg (non-soapbox) and Keith (soapbox) for the answers. Both show valid insights and hopefully will help the next novice to come by. I would like to keep up this dialog if possible as I stumble forward in my quest to figure all of this out. Maybe we can come up with a intro document of some type. I have worked up a document on how to get openldap and openssl libs working with one another. If there is a place for me to post it I'd be happy to. After all the hub bub I did get libcgi working only to find that the library itself was lacking some functionality I needed. I am now moving onto cgic (http://www.boutell.com/cgic/) to see if that better fits my needs... If anyone has any good recommendation for C (not c++) based libraries for CGI, MIME, SMTP etc please pass them forward. Many thanks Eric Keith Marshall wrote: > On Monday 08 June 2009 01:28:18 Eric Nichols wrote: >> Bad news. MinGW's gcc specification of libraries is VERY >> specific. A clue on this can be found in the docs: >> > http://www.mingw.org/wiki/Specify_the_libraries_for_the_linker_to_use > > And that page provides information which is generic to the GNU > linker. WRT the placement of library specifications on the link > command line, it applies to *any* platform which uses this linker, > and is in no way MinGW specific; (the association of -lname with the > MS compatible alternative name.lib convention is the only exception; > it applies for MinGW and Cygwin, but not for *nix platforms). > >> So when building the example programs the Makefile had: >> $(CC) $(FLAGS) -lcgi gbook.c -o @(CGIBIN)/gbook.cgi > > Well, this is just plain invalid: nothing to do with MinGW; it is > *wrong* on *every* platform using the GNU linker. OTOH... > >> In MinGW you have to specify the library LAST: >> $(CC) $(FLAGS) gbook.c -o @(CGIBIN)/gbook.cgi -lcgi > > ...this is correct, (except that it should surely be $(CGIBIN)/... > rather than @(CGIBIN)/...), not just for MinGW, but on *every* GNU > or generic UNIX platform. > >> Obviously this is a know issue (it's documented). > > Yes, and it's documented in the *generic* GCC and GNU binutils > manuals, as applicable to *every* supported platform: > http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options > http://sourceware.org/binutils/docs/ld/Options.html#index-archive-files_002c-from-cmd-line-52 > (latter equivalent to http://tinyurl.com/nrkahr in case of wrapping). > >> Is there any reason why this is the case? > > Yes; because this is how it has always been, on UNIX systems in > general, from time immemorial, (i.e. since the birth of UNIX). > >> For the uninitiated (like me) this is a speed bump to porting code >> that probably shouldn't be? > > No, it shouldn't be. However, I do wish that the uninitiated (like > you) would resist the temptation to immediately point the finger of > blame at MinGW; rather first check your own understanding of the > facts, (by searching list archives; I've lost count of the number of > times this has been erroneously reported, even quite recently). > Only when you are sure of your ground, then go shout at all those > careless developers who write their Makefiles with invalid linking > command syntax, (or maybe, the developers of those ELF linkers, who > carelessly let them get away with writing those invalid commands in > the first instance). Better yet, just quietly point those careless > developers at the appropriate documentation, and send them patches > to correct their defective Makefiles. This is *not* a MinGW bug! > > Please review the additions I've made today, to the FAQ page you > originally cited: http://tinyurl.com/m8ddzz > |
From: Keith M. <kei...@us...> - 2009-06-10 16:45:20
|
On Wednesday 10 June 2009 00:28:08 Eric Nichols wrote: > Many thanks to both Greg (non-soapbox) and Keith (soapbox) for the > answers. Both show valid insights and hopefully will help the > next novice to come by. Call it preaching from a soapbox, if you wish. I try to be helpful, but it does become frustrating, when I find myself responding to yet another report on the same feature, which is *not* a MinGW bug, but a bug in the user's code, (or a gap in their understanding, coupled with inadequate research), for the third, fourth or even fifth time. FWIW, the issue you raised had already been comprehensively discussed on this very list, (and not for the first time), as recently as the end of last year; (this was posted on 20-Dec-2008): http://thread.gmane.org/gmane.comp.gnu.mingw.user/28512/focus=28523 You should also read: http://catb.org/esr/faqs/smart-questions.html (a copy of which may also be found at): http://linuxmafia.com/faq/Essays/smart-questions.html Would you prefer it, if I were to adopt Eric's and Rick's philosophy of thinking "What a luser", as I condemn your message to the trash, without offering any insight at all? > I would like to keep up this dialog if possible as I stumble > forward in my quest to figure all of this out. By all means, but unless it's a strict continuation of the discussion on libcgi, specifically, please create a new message thread for each new topic you wish to pursue. Also, when you do continue an existing thread, please do not top-post; (that is a certain way to guarantee a dearth of answers; there should be no residual quoted content, after your own signature). > Maybe we can come > up with a intro document of some type. I have worked up a > document on how to get openldap and openssl libs working with one > another. If there is a place for me to post it I'd be happy to. That would be as a new Wiki page on http://mingw.org, please, with an appropriate reference link added to "Documentation --> HOWTO". -- Regards, Keith. |