From: Thom D. <tho...@co...> - 2006-01-22 04:20:03
|
Hey, When I try linking with "-lm" I get a pile of undefined references. The only libm.a that I find in my MinGW/MSYS installation is /mingw/lib/libm.a But, this file is only 485 bytes in size. It certainly seems like that must not be a complete file. Is there something wrong with my installation? What should I look for to fix it? Thanks, Thom -- Thom DeCarlo -=-=- "Some days I feel like I'm limping away from the scene of a terrible accident that left my youth by the side of the road in a tangled, smoking heap."-Jerry Smith- |
From: Brian D. <br...@de...> - 2006-01-22 04:33:26
|
Thom DeCarlo wrote: > When I try linking with "-lm" I get a pile of undefined references. The > only libm.a that I find in my MinGW/MSYS installation is > /mingw/lib/libm.a > > But, this file is only 485 bytes in size. It certainly seems like that > must not be a complete file. Is there something wrong with my > installation? What should I look for to fix it? You shouldn't need to do anything special to link math functions. There should no need for -lm because they are not in a separate library. It should just work, since all the math functions are in MSVCRT and/or libmingwex.a, both of which should be found and used automatically without any action from the user. If you are getting errors it would be helpful to know the *exact* command line you are using to link, the *exact* errors you are getting, and the nature of your source code -- a simple standalone test case would be best. Most linking problems seem to be due to simply getting the order wrong on the command line. Brian |
From: Earnie B. <ea...@us...> - 2006-01-22 15:56:10
|
Quoting Brian Dessent <br...@de...>: > Thom DeCarlo wrote: > >> When I try linking with "-lm" I get a pile of undefined references. The >> only libm.a that I find in my MinGW/MSYS installation is >> /mingw/lib/libm.a >> >> But, this file is only 485 bytes in size. It certainly seems like that >> must not be a complete file. Is there something wrong with my >> installation? What should I look for to fix it? > > You shouldn't need to do anything special to link math functions. There > should no need for -lm because they are not in a separate library. It > should just work, since all the math functions are in MSVCRT and/or > libmingwex.a, both of which should be found and used automatically > without any action from the user. > > If you are getting errors it would be helpful to know the *exact* > command line you are using to link, the *exact* errors you are getting, > and the nature of your source code -- a simple standalone test case > would be best. Most linking problems seem to be due to simply getting > the order wrong on the command line. > And to answer the question about the size of -lm and its purpose; libm.a is an empty archive whose purpose is to help the brain dead UNIX Makefiles that always add -lm regardless of its need. It was created to help porters of UNIX software not need to worry with the broken build process. Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Tim T. <ra...@ed...> - 2006-01-23 18:25:39
|
Hello! > And to answer the question about the size of -lm and its purpose; libm.a > is an empty archive whose purpose is to help the brain dead UNIX > Makefiles that always add -lm regardless of its need. It was created to > help porters of UNIX software not need to worry with the broken build > process. My configure.ac script does the following: AC_CHECK_LIB(m,sin,,,) and thus always would add -lm for under mingw since it does not hurt linking against the empty archive. Doing some research I found a configure.ac that uses ACE_CHECK_FUNCT(sin) and doing a blindly LIBS="$LIBS -lm" in the error cases, which does not look better since it still does not test for libm (would however have left out "-lm" under mingw). How do I correctly check for libm instead? -- Gruß... Tim. |
From: Ralf W. <Ral...@gm...> - 2006-01-23 18:29:26
|
Hi Tim, * Tim Teulings wrote on Mon, Jan 23, 2006 at 07:25:26PM CET: > > My configure.ac script does the following: > > AC_CHECK_LIB(m,sin,,,) > > and thus always would add -lm for under mingw since it does not hurt > linking against the empty archive. *snip* > How do I correctly check for libm instead? You could use AC_SEARCH_LIBS([sqrt], [m]) Cheers, Ralf |
From: Thom D. <tho...@co...> - 2006-01-27 02:33:15
|
Ralf Wildenhues wrote: > Hi Tim, > > * Tim Teulings wrote on Mon, Jan 23, 2006 at 07:25:26PM CET: > >>My configure.ac script does the following: >> >>AC_CHECK_LIB(m,sin,,,) >> >>and thus always would add -lm for under mingw since it does not hurt >>linking against the empty archive. > > *snip* > >>How do I correctly check for libm instead? > > > You could use > AC_SEARCH_LIBS([sqrt], [m]) > > Cheers, > Ralf > Ralf, This test succeeded in my configure. (Though I had to download and install the new version of autoconf. This package complained that it needed at least autoconf 2.59. Any idea when the new version will be rolled into MinGW?) However, it didn't fix the problem with linker. It is still complaining about not finding things that are supposed to be in the math library. In fact, closer examination (CTRL-C before the first error messages scroll out of the buffer) shows that even things like sprintf, atoi, and atof are not being found. It is starting to feel like there is something in the Makefile that is causing the linker to ignore the standard libraries. More info: I'm trying to build the geotiff libraries and the prerequisites (libtiff, proj, and jpeg). The other three packages compile and link with no problems. But, I've had no luck (or at least no *good* luck) getting the geotiff package to build. And I'm not getting any response at all from the geotiff mailing list. With much snippage of duplicate lines, this is what I get when I try to build libgeotiff. Can anyone see any obvious problems with this? TIA, Thom OBTW, my LIBDIR enviroment variable is "/usr/local/lib:/mingw/lib" thom@HATTER /s/osg/geotiff/libgeotiff $ make rm -f xtiffio.h ln -s ./libxtiff/*.h . gcc -c -O2 -Wall -DCSV_DATA_DIR=\"/usr/local/share/epsg_csv\" -I. -I. -I/usr/local/include -I/usr/local/include ./libxtiff/xtiff.c gcc -c -O2 -Wall -DCSV_DATA_DIR=\"/usr/local/share/epsg_csv\" -I. -I. -I/usr/local/include -I/usr/local/include ./geo_free.c gcc -c -O2 -Wall -DCSV_DATA_DIR=\"/usr/local/share/epsg_csv\" -I. -I. -I/usr/local/include -I/usr/local/include ./geo_get.c gcc -c -O2 -Wall -DCSV_DATA_DIR=\"/usr/local/share/epsg_csv\" -I. -I. -I/usr/local/include -I/usr/local/include ./geo_names.c gcc -c -O2 -Wall -DCSV_DATA_DIR=\"/usr/local/share/epsg_csv\" -I. -I. -I/usr/local/include -I/usr/local/include ./geo_new.c gcc -c -O2 -Wall -DCSV_DATA_DIR=\"/usr/local/share/epsg_csv\" -I. -I. -I/usr/local/include -I/usr/local/include ./geo_print.c gcc -c -O2 -Wall -DCSV_DATA_DIR=\"/usr/local/share/epsg_csv\" -I. -I. -I/usr/local/include -I/usr/local/include ./geo_set.c gcc -c -O2 -Wall -DCSV_DATA_DIR=\"/usr/local/share/epsg_csv\" -I. -I. -I/usr/local/include -I/usr/local/include ./geo_tiffp.c gcc -c -O2 -Wall -DCSV_DATA_DIR=\"/usr/local/share/epsg_csv\" -I. -I. -I/usr/local/include -I/usr/local/include ./geo_write.c gcc -c -O2 -Wall -DCSV_DATA_DIR=\"/usr/local/share/epsg_csv\" -I. -I. -I/usr/local/include -I/usr/local/include ./geo_trans.c gcc -c -O2 -Wall -DCSV_DATA_DIR=\"/usr/local/share/epsg_csv\" -I. -I. -I/usr/local/include -I/usr/local/include ./geo_normalize.c gcc -c -O2 -Wall -DCSV_DATA_DIR=\"/usr/local/share/epsg_csv\" -I. -I. -I/usr/local/include -I/usr/local/include ./geotiff_proj4.c gcc -c -O2 -Wall -DCSV_DATA_DIR=\"/usr/local/share/epsg_csv\" -I. -I. -I/usr/local/include -I/usr/local/include ./geo_extra.c gcc -c -O2 -Wall -DCSV_DATA_DIR=\"/usr/local/share/epsg_csv\" -I. -I. -I/usr/local/include -I/usr/local/include ./cpl_serv.c gcc -c -O2 -Wall -DCSV_DATA_DIR=\"/usr/local/share/epsg_csv\" -I. -I. -I/usr/local/include -I/usr/local/include ./cpl_csv.c ar r libgeotiff.a xtiff.o geo_free.o geo_get.o geo_names.o geo_new.o geo_print.o geo_set.o geo_tiffp.o geo_write.o geo_trans.o geo_normalize.o geotiff_proj4.o geo_extra.o cpl_serv.o cpl_csv.o ranlib libgeotiff.a ld -shared xtiff.o geo_free.o geo_get.o geo_names.o geo_new.o geo_print.o geo_set.o geo_tiffp.o geo_write.o geo_trans.o geo_normalize.o geotiff_proj4.o geo_extra.o cpl_serv.o cpl_csv.o -L/usr/local/lib -lproj -L/usr/local/lib -ltiff -L/usr/local/lib -lz -L/usr/local -ljpeg -o libgeotiff.so.1.2.2 geo_names.o(.text+0xb088):geo_names.c: undefined reference to `sprintf' geo_names.o(.text+0xb231):geo_names.c: undefined reference to `strcmp' geo_names.o(.text+0xb27e):geo_names.c: undefined reference to `sscanf' geo_print.o(.text+0xf6):geo_print.c: undefined reference to `sprintf' geo_print.o(.text+0x1ed):geo_print.c: more undefined references to `sprintf' follow geo_print.o(.text+0x2ab):geo_print.c: undefined reference to `_imp___iob' geo_print.o(.text+0x824):geo_print.c: undefined reference to `sscanf' geo_print.o(.text+0x859):geo_print.c: undefined reference to `sscanf' geo_print.o(.text+0x913):geo_print.c: undefined reference to `_imp___iob' geo_print.o(.text+0x95b):geo_print.c: undefined reference to `_imp___iob' geo_print.o(.text+0x969):geo_print.c: undefined reference to `fprintf' geo_print.o(.text+0x1054):geo_print.c: undefined reference to `fscanf' geo_print.o(.text+0x781):geo_print.c: undefined reference to `fprintf' geo_set.o(.text+0x279):geo_set.c: undefined reference to `strlen' geo_set.o(.text+0x347):geo_set.c: undefined reference to `_assert' geo_tiffp.o(.text+0x15f):geo_tiffp.c: undefined reference to `strlen' geo_normalize.o(.text+0x2b2):geo_normalize.c: undefined reference to `atof' geo_normalize.o(.text+0x2c5):geo_normalize.c: undefined reference to `atof' geo_normalize.o(.text+0x33f):geo_normalize.c: undefined reference to `strchr' geo_normalize.o(.text+0x35a):geo_normalize.c: undefined reference to `strlen' geo_normalize.o(.text+0xba1):geo_normalize.c: undefined reference to `fopen' geo_normalize.o(.text+0xbb5):geo_normalize.c: undefined reference to `fclose' geo_normalize.o(.text+0x2e36):geo_normalize.c: undefined reference to `stricmp' geo_normalize.o(.text+0x2e77):geo_normalize.c: undefined reference to `sprintf' geo_normalize.o(.text+0x30fb):geo_normalize.c: undefined reference to `fprintf' geo_normalize.o(.text+0x3485):geo_normalize.c: undefined reference to `strstr' geotiff_proj4.o(.text+0x98d):geotiff_proj4.c: undefined reference to `strdup' geotiff_proj4.o(.text+0x9b4):geotiff_proj4.c: undefined reference to `strcat' geotiff_proj4.o(.text+0xa50):geotiff_proj4.c: undefined reference to `sprintf' geotiff_proj4.o(.text+0xac5):geotiff_proj4.c: undefined reference to `sprintf' geotiff_proj4.o(.text+0xbd7):geotiff_proj4.c: undefined reference to `sprintf' geotiff_proj4.o(.text+0x1131):geotiff_proj4.c: undefined reference to `sprintf' geotiff_proj4.o(.text+0x12f6):geotiff_proj4.c: undefined reference to `free' geotiff_proj4.o(.text+0x13e6):geotiff_proj4.c: undefined reference to `free' cpl_serv.o(.text+0x211):cpl_serv.c: undefined reference to `strlen' cpl_serv.o(.text+0x22c):cpl_serv.c: undefined reference to `strcpy' cpl_serv.o(.text+0x23e):cpl_serv.c: undefined reference to `strlen' cpl_serv.o(.text+0x2db):cpl_serv.c: undefined reference to `fgets' cpl_serv.o(.text+0x6d0):cpl_serv.c: undefined reference to `strchr' cpl_serv.o(.text+0x71a):cpl_serv.c: undefined reference to `vsprintf' cpl_serv.o(.text+0x756):cpl_serv.c: undefined reference to `_imp___iob' cpl_serv.o(.text+0x765):cpl_serv.c: undefined reference to `fprintf' cpl_serv.o(.text+0x76c):cpl_serv.c: undefined reference to `abort' cpl_csv.o(.text+0x38):cpl_csv.c: undefined reference to `stricmp' cpl_csv.o(.text+0x53):cpl_csv.c: undefined reference to `fopen' cpl_csv.o(.text+0xd0):cpl_csv.c: undefined reference to `stricmp' cpl_csv.o(.text+0x18b):cpl_csv.c: undefined reference to `fclose' cpl_csv.o(.text+0x3e9):cpl_csv.c: undefined reference to `fseek' cpl_csv.o(.text+0x3f2):cpl_csv.c: undefined reference to `ftell' cpl_csv.o(.text+0x3fd):cpl_csv.c: undefined reference to `rewind' cpl_csv.o(.text+0x417):cpl_csv.c: undefined reference to `fread' cpl_csv.o(.text+0x4dd):cpl_csv.c: undefined reference to `fclose' cpl_csv.o(.text+0x4fb):cpl_csv.c: undefined reference to `atoi' cpl_csv.o(.text+0x5bd):cpl_csv.c: undefined reference to `strchr' cpl_csv.o(.text+0x611):cpl_csv.c: undefined reference to `strlen' cpl_csv.o(.text+0x633):cpl_csv.c: undefined reference to `strcat' cpl_csv.o(.text+0x6cc):cpl_csv.c: undefined reference to `stricmp' cpl_csv.o(.text+0x6dc):cpl_csv.c: undefined reference to `strcmp' cpl_csv.o(.text+0x9b7):cpl_csv.c: undefined reference to `rewind' cpl_csv.o(.text+0xbfe):cpl_csv.c: undefined reference to `getenv' cpl_csv.o(.text+0xc11):cpl_csv.c: undefined reference to `sprintf' cpl_csv.o(.text+0xc24):cpl_csv.c: undefined reference to `fclose' C:/msys/1.0/local/lib/libproj.a(pj_inv.o)(.text+0x4a): In function `pj_inv': s:/OSG/proj/src/pj_inv.c:14: undefined reference to `_imp___HUGE' C:/msys/1.0/local/lib/libproj.a(pj_inv.o)(.text+0x96):s:/OSG/proj/src/pj_inv.c:18: undefined reference to `_errno' C:/msys/1.0/local/lib/libproj.a(pj_inv.o)(.text+0xfb):s:/OSG/proj/src/pj_inv.c:23: undefined reference to `_imp___HUGE' C:/msys/1.0/local/lib/libproj.a(pj_inv.o)(.text+0x133):s:/OSG/proj/src/pj_inv.c:32: undefined reference to `_errno' C:/msys/1.0/local/lib/libproj.a(pj_inv.o)(.text+0x184):s:/OSG/proj/src/pj_inv.c:29: undefined reference to `tan' C:/msys/1.0/local/lib/libproj.a(pj_inv.o)(.text+0x18f):s:/OSG/proj/src/pj_inv.c:29: undefined reference to `atan' C:/msys/1.0/local/lib/libproj.a(pj_init.o)(.text+0x71): In function `get_opt' -- Thom DeCarlo -=-=- Someone who thinks logically provides a nice contrast to the real world. |
From: Brian D. <br...@de...> - 2006-01-27 02:57:10
|
Thom DeCarlo wrote: > ld -shared xtiff.o geo_free.o geo_get.o geo_names.o geo_new.o > geo_print.o geo_set.o geo_tiffp.o geo_write.o geo_trans.o > geo_normalize.o geotiff_proj4.o geo_extra.o cpl_serv.o cpl_csv.o > -L/usr/local/lib -lproj -L/usr/local/lib -ltiff -L/usr/local/lib -lz > -L/usr/local -ljpeg -o libgeotiff.so.1.2.2 This is your problem. You should never link with ld directly unless you know precisely what you're doing. Use gcc to link, because it will add all the necessary platform-specific libraries, flags, and objects. Brian |
From: Thom D. <tho...@co...> - 2006-01-27 22:07:43
|
Brian Dessent wrote: > Thom DeCarlo wrote: > > >>ld -shared xtiff.o geo_free.o geo_get.o geo_names.o geo_new.o >>geo_print.o geo_set.o geo_tiffp.o geo_write.o geo_trans.o >>geo_normalize.o geotiff_proj4.o geo_extra.o cpl_serv.o cpl_csv.o >>-L/usr/local/lib -lproj -L/usr/local/lib -ltiff -L/usr/local/lib -lz >>-L/usr/local -ljpeg -o libgeotiff.so.1.2.2 > > > This is your problem. You should never link with ld directly unless you > know precisely what you're doing. Use gcc to link, because it will add > all the necessary platform-specific libraries, flags, and objects. > > Brian > Brian and Greg, Thanks! I'll try changing that in my makefiles. (You touched on the *real* problem, though. I have only the faintest glimmering of a notion of what I'm doing. :-) ) I didn't write any of these packages, they are all projects that I have gotten from other sources. Thanks for the info. Thom -- Thom DeCarlo -=-=- Jesus Saves, but Cthulhu saves you for last... |
From: Greg C. <chi...@co...> - 2006-01-27 03:03:23
|
On 2006-1-27 2:33 UTC, Thom DeCarlo wrote: > > It is starting to feel like there is something in > the Makefile that is causing the linker to ignore the standard libraries. The usual cause of that is using 'ld' directly. Instead, use 'gcc' to link C, or 'g++' to link C++ and then the usually-necessary libraries will be linked for you. You can use 'ld' and specify them yourself, but that's too much work. > thom@HATTER /s/osg/geotiff/libgeotiff > $ make > ld -shared xtiff.o geo_free.o geo_get.o geo_names.o geo_new.o ^^ > geo_print.o geo_set.o geo_tiffp.o geo_write.o geo_trans.o > geo_normalize.o geotiff_proj4.o geo_extra.o cpl_serv.o cpl_csv.o > -L/usr/local/lib -lproj -L/usr/local/lib -ltiff -L/usr/local/lib -lz > -L/usr/local -ljpeg -o libgeotiff.so.1.2.2 > geo_names.o(.text+0xb088):geo_names.c: undefined reference to `sprintf' Try 'make LD=gcc'; that might make this makefile work. |
From: Keith M. <kei...@to...> - 2006-01-27 09:55:24
|
Thom DeCarlo wrote: > This package complained that it needed at least autoconf 2.59. > Any idea when the new version will be rolled into MinGW?) Autoconf-2.59 *is* the latest version, (from the GNU project). You can install it yourself, from official GNU sources, but MinGW *already* has it prepackaged: http://prdownloads.sourceforge.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sourceforge.net/mingw/msys-autoconf-2.59.tar.bz2?download You choose whether you want to use the mingwPORT package, which automates the download, build and installation from the official GNU sources, or use the prepackaged MSYS Developer's Toolkit variant. As for rolling this into an integrated msysDTK download package, that may never happen. My own preference is to offer individually packaged tools, and allow users the freedom to download only what they require, rather than force them to download a bunch of stuff they may never use, just for one component. See also Earnie's comment here: http://sourceforge.net/mailarchive/message.php?msg_id=14610012 Regards, Keith. |
From: Thom D. <tho...@co...> - 2006-01-27 22:27:04
|
Keith MARSHALL wrote: > Thom DeCarlo wrote: > >>This package complained that it needed at least autoconf 2.59. >>Any idea when the new version will be rolled into MinGW?) > > > Autoconf-2.59 *is* the latest version, (from the GNU project). > You can install it yourself, from official GNU sources, but MinGW > *already* has it prepackaged: > http://prdownloads.sourceforge.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download > http://prdownloads.sourceforge.net/mingw/msys-autoconf-2.59.tar.bz2?download > > You choose whether you want to use the mingwPORT package, which > automates the download, build and installation from the official GNU > sources, or use the prepackaged MSYS Developer's Toolkit variant. > > As for rolling this into an integrated msysDTK download package, > that may never happen. My own preference is to offer individually > packaged tools, and allow users the freedom to download only what > they require, rather than force them to download a bunch of stuff > they may never use, just for one component. See also Earnie's > comment here: > http://sourceforge.net/mailarchive/message.php?msg_id=14610012 > > Regards, > Keith. > Hi Keith, I hope you don't think I was being critical, that wasn't my intention. The version of autoconf that I found in my MinGW/MSYS/msysDTK was 2.56. I did download and install 2.59 with only a little bit of trouble. (I had to rename the autoconf.exe in /bin so that it wasn't used by default.) I guess what I need to figure out is, should I download the DTK or find each of the components as I need them. I'm not entirely certain what is in the DTK, so I'm not sure what dependencies are in place. Thanks, Thom -- Thom DeCarlo -=-=- If you understand it, it must be obsolete. - James Burke |
From: Keith M. <kei...@to...> - 2006-01-30 13:37:30
|
Thom DeCarlo wrote: > I hope you don't think I was being critical, that wasn't my > intention. Not at all. You asked a question; I supplied an answer. I made no assumption of criticism, nor intended any in my reply; sorry, if it came over that way. > The version of autoconf that I found in my MinGW/MSYS/msysDTK was > 2.56. I did download and install 2.59 with only a little bit of > trouble. (I had to rename the autoconf.exe in /bin so that it > wasn't used by default.) There should not have been any `autoconf.exe'; the `autoconf' in the DTK is a Bourne shell script, which should be replaced by the new version, if you install either of the upgrade kits into the root of your MSYS tree. > I guess what I need to figure out is, should I download the DTK or > find each of the components as I need them. I'm not entirely certain > what is in the DTK, so I'm not sure what dependencies are in place. Yes, that is a problem. There is a partial listing of the contents available via the `notes' link, on the package heading bar of the SF files catalogue. We should complete this listing; perhaps we should also consider reproducing it, say on MinGWiki? msysDTK-1.0.1.exe is now quite old. Unfortunately, it isn't obvious from the SF files catalogue, that the component packages listed under the `Current->MSYS Developer Tool Kit' heading, that the component packages supercede the composite distribution, and are intended to update it. As I said previously, I favour separating the tool kit into its component packages, each independently downloaded; that way, users may select just the components they actually require. A possible disadvantage of this is that users would then be left to resolve dependencies for themselves; e.g. the autotools require `perl', which is included in msysDTK, but isn't mentioned in the `notes', so users could be left floundering over this missing dependency. A solution to this would be to provide an integrated installer, much like MinGW-5.0.0.exe, which could allow the user to select the components he would like, and automatically include the additional dependencies. However, to make that possible, I would need a volunteer to both develop and *maintain* such an installer; (Dave Murphy, having developed MinGW-5.0.0.exe, now seems to have dropped off the radar, leaving no one to maintain it :-( ). Regards, Keith. |