From: Alex C. <ale...@gm...> - 2013-10-18 19:38:39
|
I am trying to build a library (DLL) that contains functions used by my database engine, Codebase. In addition to the Codebase functions and some front ends to simplify the calls to them, there are some components of gtk+-2.0 and gmodule-2.0. I have created a C source file called cbfunx.c. Note that I am initially building with debugging symbols included. I am struggling with the syntax of the compile and link commands. It actually appears that the compile command is working, but the link command is failing. I have tried re-arranging various parts of the command and gotten different results, but none of them seems to produce a usable library. The library files libcb.a and zlib.lib are contained in /home/alex/gtk/plugins Here is the compile command I am using: gcc -c -g -DBUILDING_DLL -DWIN32 cbfunx.c -mwindows \ `pkg-config --cflags gtk+-2.0 gmodule-2.0` \ -IC:/home/alex/gtk/Codebase/source \ -IC:/home/alex/gtk/plugins \ `pkg-config --libs gtk+-2.0 gmodule-2.0` \ -lC:/home/alex/gtk/plugins \ -lcb -o cbfunx.o This compile completes without errors and generates cbfunx.o as expected. Here is the link command I am using. gcc -g -shared \ -Wl,--out-implib,libcfunx.a \ -mwindows \ `pkg-config --libs gtk+-2.0 gmodule-2.0` \ -LC:/home/alex/gtk/plugins \ -lcb -lzlib -lmingw32 \ -o cbfunx.dll cbfunx.o This link command fails and produces numerous errors stating undefined references to functions that are contained in libcb.a. It is as if the "-lcb" flag is being ignored. Can someone please tell me what I am doing wrong? |
From: Keith M. <kei...@us...> - 2013-10-18 20:42:43
|
On 18/10/13 20:38, Alex Chigos wrote: > I am struggling with the syntax of the compile and link commands. It > actually appears that the compile command is working, but the link > command is failing. ... > Here is the compile command I am using: > > gcc -c -g -DBUILDING_DLL -DWIN32 cbfunx.c -mwindows \ Why are you defining WIN32? You should leave that to the compiler. Also, cbfunx.c seems too early here. > `pkg-config --cflags gtk+-2.0 gmodule-2.0` \ > -IC:/home/alex/gtk/Codebase/source \ > -IC:/home/alex/gtk/plugins \ This is where cbfunx.c should be specified. > `pkg-config --libs gtk+-2.0 gmodule-2.0` \ > -lC:/home/alex/gtk/plugins \ I assume this is a typo; did you mean -LC:/home/alex/gtk/plugins ? Do you really have headers and libraries mixed together, in this one common directory? > -lcb -o cbfunx.o > > This compile completes without errors and generates cbfunx.o as expected. I'm surprised, given your placement of cbfunx.c; maybe GCC is less picky about ordering of source control flags, relative to source code files, that I would expect. > Here is the link command I am using. > > gcc -g -shared \ > -Wl,--out-implib,libcfunx.a \ > -mwindows \ Your cbfunx.o should come here. > `pkg-config --libs gtk+-2.0 gmodule-2.0` \ > -LC:/home/alex/gtk/plugins \ > -lcb -lzlib -lmingw32 \ Once again, you should be leaving it to the compiler driver, to specify -lmingw32 for you; the other two, you do need to specify, but here, they will provide nothing, because the unresolved symbol table is empty at this point, in the processing of this command; (no object modules specified). > -o cbfunx.dll cbfunx.o > > This link command fails and produces numerous errors stating undefined > references to functions that are contained in libcb.a. It is as if the > "-lcb" flag is being ignored. It is, because by the time the linker gets to processing cbfunx.o it has already processed -lcb and -lzlib, and discarded them as providing nothing useful in the context of the (empty) symbol table; cbfunx.o is way too late in the argument order. > Can someone please tell me what I am doing wrong? You are breaking all the rules of argument ordering; for about the gadzillionth time, this is IMPORTANT! Object files MUST be specified BEFORE the library files on which they depend. It has been so since the dawn of the Unix epoch, yet far too many people continue to get this wrong! -- Regards, Keith. |
From: Kirk J. <kir...@gm...> - 2013-10-20 20:28:26
|
> You are breaking all the rules of argument ordering; for about the > gadzillionth time, this is IMPORTANT! Object files MUST be specified > BEFORE the library files on which they depend. It has been so since the > dawn of the Unix epoch, yet far too many people continue to get this wrong! You know, it's not that everyone is stupid. This detail only ever comes up on mailing lists and usually as an answer to a question with an unrelated title. Thus nobody ever finds this information. Such was the case with me at first. Figuring out why linking fails is far from clear for anyone new to the tools. |
From: Keith M. <kei...@us...> - 2013-10-20 21:26:44
|
On 20/10/13 21:28, Kirk Joppy wrote: >> You are breaking all the rules of argument ordering; for about the >> gadzillionth time, this is IMPORTANT! Object files MUST be specified >> BEFORE the library files on which they depend. It has been so since the >> dawn of the Unix epoch, yet far too many people continue to get this wrong! > > You know, it's not that everyone is stupid. This detail only ever > comes up on mailing lists and usually as an answer to a question with > an unrelated title. Thus nobody ever finds this information. Such was > the case with me at first. Figuring out why linking fails is far from > clear for anyone new to the tools. Oh, come now. That's a thoroughly lame excuse. You could RTFM: http://bit.ly/16p2Lfp Or just: http://bit.ly/16p2j0t -- Regards, Keith. |
From: Renato S. <br....@gm...> - 2013-10-21 01:21:17
|
And you could SBFA. Interesting, you prefer waste your time with "stupid" questions than just ignoring. We all know why. On 20/10/13 21:28, Kirk Joppy wrote: >> You are breaking all the rules of argument ordering; for about the >> gadzillionth time, this is IMPORTANT! Object files MUST be specified >> BEFORE the library files on which they depend. It has been so since the >> dawn of the Unix epoch, yet far too many people continue to get this wrong! > > You know, it's not that everyone is stupid. This detail only ever > comes up on mailing lists and usually as an answer to a question with > an unrelated title. Thus nobody ever finds this information. Such was > the case with me at first. Figuring out why linking fails is far from > clear for anyone new to the tools. Oh, come now. That's a thoroughly lame excuse. You could RTFM: http://bit.ly/16p2Lfp Or just: http://bit.ly/16p2j0t -- Regards, Keith. ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ MinGW-users mailing list Min...@li... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users Also: mailto:min...@li...?subject=unsubscribe |
From: Peter R. <p.r...@sh...> - 2013-10-21 10:00:53
|
On 20/10/13 22:26, Keith Marshall wrote: > On 20/10/13 21:28, Kirk Joppy wrote: >>> You are breaking all the rules of argument ordering; for about the >>> gadzillionth time, this is IMPORTANT! Object files MUST be specified >>> BEFORE the library files on which they depend. It has been so since the >>> dawn of the Unix epoch, yet far too many people continue to get this wrong! >> You know, it's not that everyone is stupid. This detail only ever >> comes up on mailing lists and usually as an answer to a question with >> an unrelated title. Thus nobody ever finds this information. Such was >> the case with me at first. Figuring out why linking fails is far from >> clear for anyone new to the tools. > Oh, come now. That's a thoroughly lame excuse. You could RTFM: > http://bit.ly/16p2Lfp Or just: http://bit.ly/16p2j0t > Except this issue comes up sufficiently frequently that you either have to infer that a large fraction of new MinGW users are congenitally dumb, or the information really is not obvious. I recall when I first came to MinGW, it took me ages to discover that the documentation for the linker is (unobviously) included in the binutils collection. And the linker is unhelpfully called "ld". (Yeah, yeah. I now it comes from "loader" but that's from a bygone era). Long time since I used it but, if I recall, the MSVC linker does not display this ordering behaviour. So anybody coming over to MinGW from the 'dark side' could be excused for being nonplussed. I appreciate Keith's frustration on this but, IMO, this really is an genuine idiosyncrasy so is likely to continue to trip people up. P. |
From: JonY <jo...@us...> - 2013-10-21 10:20:22
Attachments:
signature.asc
|
On 10/21/2013 18:00, Peter Rockett wrote: > Long time since I used it but, if I recall, the MSVC linker does not > display this ordering behaviour. So anybody coming over to MinGW from > the 'dark side' could be excused for being nonplussed. This behavior was exhibited since the early ages, do not ask to change the default behavior, ever, especially one that has been established for more than 2 decades. |
From: Peter R. <p.r...@sh...> - 2013-10-21 10:35:48
|
On 21/10/13 11:20, JonY wrote: > On 10/21/2013 18:00, Peter Rockett wrote: >> Long time since I used it but, if I recall, the MSVC linker does not >> display this ordering behaviour. So anybody coming over to MinGW from >> the 'dark side' could be excused for being nonplussed. > This behavior was exhibited since the early ages, do not ask to change > the default behavior, ever, especially one that has been established for > more than 2 decades. That is not the point I'm making! What I am saying is that anybody with (possibly substantial) experience with MSVC (and maybe other toolchains) coming to MinGW is likely to find the ordering behaviour of ld perplexing. This is further compounded by an another accident of history which places the linker docs completely separate from the compiler docs. "Utilities" says useful add-on bits to me, not something as central as the linker. P. |
From: Earnie B. <ea...@us...> - 2013-10-21 11:24:07
|
On Mon, Oct 21, 2013 at 6:35 AM, Peter Rockett wrote: > That is not the point I'm making! What I am saying is that anybody with > (possibly substantial) experience with MSVC (and maybe other toolchains) > coming to MinGW is likely to find the ordering behaviour of ld > perplexing. This is further compounded by an another accident of history > which places the linker docs completely separate from the compiler docs. > "Utilities" says useful add-on bits to me, not something as central as > the linker. If I were having problems linking with somebodies distribution of tools I might go to their site, http://mingw.org, and look to see if I could find some documentation. I see that the site has a search box. I type in linker and instantly know something about the linker binary name. I am not saying we should poopoo the noobs but pointing the noob to do some work isn't bad. http://mingw.org/search/node/linker -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Peter R. <p.r...@sh...> - 2013-10-21 12:15:25
|
On 21/10/13 12:24, Earnie Boyd wrote: > On Mon, Oct 21, 2013 at 6:35 AM, Peter Rockett wrote: >> That is not the point I'm making! What I am saying is that anybody with >> (possibly substantial) experience with MSVC (and maybe other toolchains) >> coming to MinGW is likely to find the ordering behaviour of ld >> perplexing. This is further compounded by an another accident of history >> which places the linker docs completely separate from the compiler docs. >> "Utilities" says useful add-on bits to me, not something as central as >> the linker. > If I were having problems linking with somebodies distribution of > tools I might go to their site, http://mingw.org, and look to see if I > could find some documentation. I see that the site has a search box. > I type in linker and instantly know something about the linker binary > name. True. FWIW: I have had a skim through the ld docs which is compendious set of options, etc. and not really a noob doc. No doubt someone will prove me wrong but explicit mention of the parameter ordering didn't leap out at me. There is an obtuse mention of something in the third paragraph of Section 2.1... > I am not saying we should poopoo the noobs but pointing the > noob to do some work isn't bad. > > http://mingw.org/search/node/linker > And indeed the 9th and 10th entries in the search results tell you very explicitly about the library ordering issue. But I fear all this may be a case of a question being easy if you have seen the answer before. Which noobs haven't, of course. Curiously, searching for "undefined reference" doesn't take you to "The linker consistently giving undefined references" which is the most helpful page on the matter. You have to search for "undefined references" (plural) to find that. P. |
From: Keith M. <kei...@us...> - 2013-10-21 13:28:58
|
On 21/10/13 13:15, Peter Rockett wrote: > Curiously, searching for "undefined reference" doesn't take you to "The > linker consistently giving undefined references" which is the most > helpful page on the matter. You have to search for "undefined > references" (plural) to find that. Hmm. The search engine provided by Drupal perhaps isn't that good; I wonder: could we exploit Google's engine here? Its first hit for: site:mingw.org linker undefined reference (note the singular form), is the very page to which you refer, and it also turns up several more references than the Drupal search, all of which are likely to be pertinent. All that said, however, the first hit from the Drupal search also answers the original question, in the paragraph immediately following the first box-out, which appears early in the page introduction. The box-out itself, incidentally, is a quotation from the *GCC* manual, which also explains what the original poster was doing wrong. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2013-10-21 11:18:06
|
On 21/10/13 11:00, Peter Rockett wrote: > Long time since I used it but, if I recall, the MSVC linker does not > display this ordering behaviour. So anybody coming over to MinGW from > the 'dark side' could be excused for being nonplussed. Last time I used a Microsoft linker was back in the days when MS-DOS was the dominant PC operating system, (and in the early days, LINK.EXE was even distributed with the OS itself); IIRC, while it may not have absolutely required it, it did encourage specifying object files before libraries; (it would even *prompt* for them, in that order, if you left the command line incomplete). > I appreciate Keith's frustration on this but, IMO, this really is an > genuine idiosyncrasy so is likely to continue to trip people up. It is frustrating, when you've lost count of the number of times you've answered this same recurring question. However, the primary goal of my previous post was to indicate that the answer can be readily found, by an obvious google search, without resorting to trawling mailing list archives, where I agree, subject headers may be less than obvious. -- Regards, Keith. |
From: Eli Z. <el...@gn...> - 2013-10-19 07:29:15
|
> Date: Fri, 18 Oct 2013 15:38:37 -0400 > From: Alex Chigos <ale...@gm...> > > gcc -g -shared \ > -Wl,--out-implib,libcfunx.a \ > -mwindows \ > `pkg-config --libs gtk+-2.0 gmodule-2.0` \ > -LC:/home/alex/gtk/plugins \ > -lcb -lzlib -lmingw32 \ > -o cbfunx.dll cbfunx.o > > This link command fails and produces numerous errors stating undefined > references to functions that are contained in libcb.a. It is as if the > "-lcb" flag is > being ignored. > > Can someone please tell me what I am doing wrong? GNU linker ld.exe is a one-pass linker, so -lcb should be after cbfunx.o, or any other object file that calls functions from libcb.a. |