From: Werner S. <sm...@ia...> - 2008-08-29 09:09:20
|
Hi, after disabling ada (cmake -G "MinGW Makefiles" -DENABLE_ada=OFF ..\..\plplot) cmake passes the configuration stage. Running make gives troubles with fortran 77 though: Scanning dependencies of target plplotf77d [ 52%] Building Fortran object bindings/f77/CMakeFiles/plplotf77d.dir/strutil.obj [ 54%] Building Fortran object bindings/f77/CMakeFiles/plplotf77d.dir/sfstubs.obj [ 55%] Building Fortran object bindings/f77/CMakeFiles/plplotf77d.dir/configurable.obj Linking Fortran shared library ..\..\dll\libplplotf77d.dll CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x54): undefined reference to `_plsetopt7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x8c): undefined reference to `_plabort7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0xc4): undefined reference to `_plsdev7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0xe1): undefined reference to `_plgdev7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x131): undefined reference to `_plsfnam7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x14e): undefined reference to `_plgfnam7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x17e): undefined reference to `_plgver7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x202): undefined reference to `_plaxes7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x26b): undefined reference to `_plbox7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x36b): undefined reference to `_plbox37_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x408): undefined reference to `_plcon07_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x4f1): undefined reference to `_plcon17_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x62c): undefined reference to `_plcon27_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x6ce): undefined reference to `_plcont7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x788): undefined reference to `_plvec07_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x88e): undefined reference to `_plvec17_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x9e6): undefined reference to `_plvec27_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0xaa5): undefined reference to `_plvect7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0xb3c): undefined reference to `_plshade07_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0xc1c): undefined reference to `_plshade17_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0xd4e): undefined reference to `_plshade27_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0xdea): undefined reference to `_plshade7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0xe98): undefined reference to `_plshades07_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0xf8f): undefined reference to `_plshades17_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x10d8): undefined reference to `_plshades27_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x118b): undefined reference to `_plshades7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x120b): undefined reference to `_plimagefr07_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x12da): undefined reference to `_plimagefr17_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x13fb): undefined reference to `_plimagefr27_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x1483): undefined reference to `_plimagefr7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x1505): undefined reference to `_pllab7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x156b): undefined reference to `_plmtex7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x15d1): undefined reference to `_plmtex37_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x1618): undefined reference to `_plptex7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x166e): undefined reference to `_plptex37_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x16ac): undefined reference to `_plstart7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x16e2): undefined reference to `_plsetmapformc_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x16fe): undefined reference to `_plmap7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x1714): undefined reference to `_plsetmapformc_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x1731): undefined reference to `_plmeridians7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x18d7): undefined reference to `_plstripc7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x1912): undefined reference to `_pltimefmt7_' CMakeFiles\plplotf77d.dir\configurable.obj:configurable.f:(.text+0x230): undefined reference to `_plparseopts7_' collect2: ld returned 1 exit status mingw32-make[2]: *** [dll/libplplotf77d.dll] Error 1 mingw32-make[1]: *** [bindings/f77/CMakeFiles/plplotf77d.dir/all] Error 2 mingw32-make: *** [all] Error 2 Any ideas? In the path I don't have f77 or g77, only gfortran. Didn't know that gfortran also compiles f77 code? Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Arjen M. <arj...@wl...> - 2008-08-29 09:15:55
|
Werner Smekal wrote: >Hi, > >after disabling ada (cmake -G "MinGW Makefiles" -DENABLE_ada=OFF >..\..\plplot) cmake passes the configuration stage. Running make gives >troubles with fortran 77 though: > >Scanning dependencies of target plplotf77d >[ 52%] Building Fortran object >bindings/f77/CMakeFiles/plplotf77d.dir/strutil.obj >[ 54%] Building Fortran object >bindings/f77/CMakeFiles/plplotf77d.dir/sfstubs.obj >[ 55%] Building Fortran object >bindings/f77/CMakeFiles/plplotf77d.dir/configurable.obj >Linking Fortran shared library ..\..\dll\libplplotf77d.dll >CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x54): undefined >reference to `_plsetopt7_' >CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x8c): undefined >reference to `_plabort7_' > > ... >undefined reference to `_plparseopts7_' >collect2: ld returned 1 exit status >mingw32-make[2]: *** [dll/libplplotf77d.dll] Error 1 >mingw32-make[1]: *** [bindings/f77/CMakeFiles/plplotf77d.dir/all] Error 2 >mingw32-make: *** [all] Error 2 > >Any ideas? In the path I don't have f77 or g77, only gfortran. Didn't >know that gfortran also compiles f77 code? > > Well, Fortran 95 is an (almost) strict superset of FORTRAN 77, so any F95 compiler should be able to handle F77 as well (*). The problem you encounter here most likely has to do with naming and calling conventions. I have never tried gfortran under MinGW (got g95 instead), but it is likely - in view of the use of DLLs - that the name in the object files should be _PLSETOPT7@xx etc. Can you check what symbols you have in the libplplotf77d.dll DLL? (via nm or strings or whatever)? Regards, Arjen |
From: Werner S. <sm...@ia...> - 2008-08-31 09:20:49
Attachments:
libplplotf77d.dll.nm.output
libplplotd.dll.nm.output
|
Hi Arjen, > Well, Fortran 95 is an (almost) strict superset of FORTRAN 77, so any F95 > compiler should be able to handle F77 as well (*). > > The problem you encounter here most likely has to do with naming and > calling > conventions. I have never tried gfortran under MinGW (got g95 instead), but > it is likely - in view of the use of DLLs - that the name in the object > files should be > _PLSETOPT7@xx etc. > > Can you check what symbols you have in the libplplotf77d.dll DLL? (via nm > or strings or whatever)? I attached the output of nm for libplplotd.dll and libplplotf77d.dll. I think that we should try to make plplot work for gfortran, since it's the standard fortran compiler of MinGW (g95 is not favoured by the MinGW guys for some reason) and it's very easily installed (e.g. http://www.miscdebris.net/plplot_wiki/index.php?title=Setup_mingw ). Regards, Werner > > Regards, > > Arjen > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Arjen M. <arj...@wl...> - 2008-09-01 04:30:47
|
> Hi Arjen, > >> Well, Fortran 95 is an (almost) strict superset of FORTRAN 77, so any >> F95 >> compiler should be able to handle F77 as well (*). >> >> The problem you encounter here most likely has to do with naming and >> calling >> conventions. I have never tried gfortran under MinGW (got g95 instead), >> but >> it is likely - in view of the use of DLLs - that the name in the object >> files should be >> _PLSETOPT7@xx etc. >> >> Can you check what symbols you have in the libplplotf77d.dll DLL? (via >> nm >> or strings or whatever)? > > I attached the output of nm for libplplotd.dll and libplplotf77d.dll. I > think that we should try to make plplot work for gfortran, since it's > the standard fortran compiler of MinGW (g95 is not favoured by the MinGW > guys for some reason) and it's very easily installed (e.g. > http://www.miscdebris.net/plplot_wiki/index.php?title=Setup_mingw ). > Hi Werner, from the nm output my guess is the trailing underscore is the problem. Well, this will require some experimentation. I will have a look at the gfortran/MinGW combination. I am fairly sure that a solution for the F77 bindings will also be a solution for the F90 bindings. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2008-09-04 14:09:54
|
Werner Smekal wrote: > > I attached the output of nm for libplplotd.dll and libplplotf77d.dll. > I think that we should try to make plplot work for gfortran, since > it's the standard fortran compiler of MinGW (g95 is not favoured by > the MinGW guys for some reason) and it's very easily installed (e.g. > http://www.miscdebris.net/plplot_wiki/index.php?title=Setup_mingw ). > Hi Werner, I have installed this new version of MinGW plus GCC, for some reason I had to restart the download a couple of times and I still have not succeeded in obtaining the make utility. But I also noticed that there does not seem to be a shell (at least not one I can get at via an icon or an entry in the Start menu). Is there a shell like bash or should I use a DOS window with an appropriate path? Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2008-09-05 06:34:56
|
Werner Smekal wrote: >Hi Arjen, > > > >No, MinGW (official and unofficial) doesn't provide a bash like shell or >something similar. I assume, that if you install (official) MSYS you >will be asked, where the MinGW directory is, and that you can use MSYS >also with the unofficial MinGW package. Otherwise just open the Windows >CLI and set the paths correctly. I wrote some lines about that in the wiki: > >http://www.miscdebris.net/plplot_wiki/index.php?title=Setup_mingw > >section Setup. If this doesn't work, or is unclear, let me know, since I >want people to easily be able to follow the instructions. > > Hi Werner, I read that section - we should probably elaborate the text a bit: I was under the impression that this would give you a complete MinGW environment, but you do need to get Msys separately. Also the file mingwvars.bat gets overwritten by the installer - with some syntax that was completely new to me (~dp0 IIRC to indicate the install directory). Under Msys the c:/mingw/bin syntax for the PATH does not work - you need to use /c/mingw/bin. Anyway, here is the situation right now: 1. I have installed the make utility from MinGW/TDM. Renamed mingw32-make.exe to make.exe 2. I have added the MinGW/bin directory to my PATH under Msys 3. which make gives that particular make.exe, so that seems to be fine (the compilers are also available) 4. CMake however complains that it can not find a proper build utility. I will have to investigate this further - CMake worked perfectly under my old installation. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2008-09-05 11:42:36
|
Hi Arjen, > I read that section - we should probably elaborate the text a bit: I was > under the > impression that this would give you a complete MinGW environment, but you > do need to get Msys separately. Also the file mingwvars.bat gets overwritten > by the installer - with some syntax that was completely new to me (~dp0 IIRC > to indicate the install directory). Under Msys the c:/mingw/bin syntax > for the > PATH does not work - you need to use /c/mingw/bin. It gives you a complete MinGW environment if you use the Windows CLI. MinGW provides all necessary libraries and headers and compilers and tools (except make) as windows executables. The compiler itself can be used from this point on, from the Windows CLI or some other IDE (e.g. CodeBlocks). MSYS is a minimal port of useful tools (bash, ls, automake, etc.) to use the MinGW tools within a unix-like environment to be able to use configure. The batch file I wrote was thought to be used within the Windows CLI not MSYS. The meaning of ~dp0 is e.g. explained here ( http://weblogs.asp.net/lorenh/archive/2006/03/24/441004.aspx ), and this is a Windows CLI command. > > Anyway, here is the situation right now: > 1. I have installed the make utility from MinGW/TDM. Renamed > mingw32-make.exe > to make.exe Don't do that, since then you'll get into troubles with MSYS. MSYS provides its own make.exe and if you rename mingw32-make.exe to make.exe strange problems might occur using MSYS. If you're not using MSYS don't mind. CMake looks for mingw32-make.exe. > 2. I have added the MinGW/bin directory to my PATH under Msys > 3. which make gives that particular make.exe, so that seems to be fine > (the compilers > are also available) > 4. CMake however complains that it can not find a proper build utility. If you are using CMake in MSYS it should look for bash.exe and maybe make.exe and gets confused, I don't know exactly. So it may be a problem due to the renaming of mingw32-make.exe. Anyways, if you want to stay with MSYS you don't need to install mingw32-make.exe anyway, so it's best to delete the files from the installation directory or reinstall the compiler tools. > > I will have to investigate this further - CMake worked perfectly under > my old installation. I'll rewrite the wiki to distinguish if the user wants to use MSYS or Windows CLI. If you want to use MinGW in the windows CLI, you have to tell CMake to use the MinGW Makefiles generator, e.g. cmake -G "MinGW Makefiles" pathtosource HTH, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2008-08-29 17:18:47
|
On 2008-08-29 11:09+0200 Werner Smekal wrote: > Hi, > > after disabling ada (cmake -G "MinGW Makefiles" -DENABLE_ada=OFF > ..\..\plplot) cmake passes the configuration stage. Running make gives > troubles with fortran 77 though: > > Scanning dependencies of target plplotf77d > [ 52%] Building Fortran object > bindings/f77/CMakeFiles/plplotf77d.dir/strutil.obj > [ 54%] Building Fortran object > bindings/f77/CMakeFiles/plplotf77d.dir/sfstubs.obj > [ 55%] Building Fortran object > bindings/f77/CMakeFiles/plplotf77d.dir/configurable.obj > Linking Fortran shared library ..\..\dll\libplplotf77d.dll > CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x54): undefined > reference to `_plsetopt7_' [...] I suspect the leading underscore on all the names is the issue. Do you have a Fortran compiler option you can use to get rid of the leading underscores? Also for the next iteration can you please use "make VERBOSE=1" to get the full build commands being used? For deeper analysis of the problem (as opposed to my guess above) do you have a tool that is equivalent of the Linux "nm" application to figure out symbols that are defined in libraries? If so, I suggest you look at the symbols in the C library being linked to by libplplotf77d.dll to see what form of plsetopt7 is defined. I suspect you will find plsetopt7_ is defined rather than _plsetopt7_ . I have the same remarks for the fortran 95 case. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Werner S. <sm...@ia...> - 2008-08-31 09:20:35
|
Hi, > I suspect the leading underscore on all the names is the issue. Do you have > a Fortran compiler option you can use to get rid of the leading underscores? Don't know, but will have a look. > > Also for the next iteration can you please use "make VERBOSE=1" to get the > full build commands being used? Sorry: Linking Fortran shared library ..\..\dll\libplplotf77d.dll cd Z:\DevZone\PLdev\build\test\bindings\f77 && C:\DevZone\cmake-2.6.0-win32-x86\bin\cmake.exe -E cmake_link_script CMakeFiles\plplotf77d.dir\link.txt --verbose=1 C:\DevZone\MinGW-4.3.1\bin\gfortran.exe -shared -o ..\..\dll\libplplotf77d.dll CMakeFiles\plplotf77d.dir\strutil.obj CMakeFiles\plplotf77d.dir\sfstubs.obj CMakeFiles\plplotf77d.dir\configurable.obj ..\..\dll\libplplotf77cd.dll.a ..\..\dll\libplplotd.dll.a ..\..\dll\libcsirocsa.dll.a CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x54): undefined reference to `_plsetopt7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x8c): undefined reference to `_plabort7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0xc4): undefined reference to `_plsdev7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0xe1): undefined reference to `_plgdev7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x131): undefined reference to `_plsfnam7_' CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x14e): undefined reference to `_plgfnam7_' > > For deeper analysis of the problem (as opposed to my guess above) do you > have a tool that is equivalent of the Linux "nm" application to figure out > symbols that are defined in libraries? If so, I suggest you look at the > symbols in the C library being linked to by libplplotf77d.dll to see what > form of plsetopt7 is defined. I suspect you will find plsetopt7_ is defined > rather than _plsetopt7_ . I did that and attached it to the reply to Arjen. > > I have the same remarks for the fortran 95 case. > > Alan Regards, Werner > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2008-08-31 15:51:09
|
On 2008-08-31 10:25+0200 Werner Smekal wrote: > Hi, > >> I suspect the leading underscore on all the names is the issue. Do you >> have >> a Fortran compiler option you can use to get rid of the leading >> underscores? > > Don't know, but will have a look. >> >> Also for the next iteration can you please use "make VERBOSE=1" to get the >> full build commands being used? > > Sorry: > > Linking Fortran shared library ..\..\dll\libplplotf77d.dll > cd Z:\DevZone\PLdev\build\test\bindings\f77 && > C:\DevZone\cmake-2.6.0-win32-x86\bin\cmake.exe -E cmake_link_script > CMakeFiles\plplotf77d.dir\link.txt --verbose=1 > C:\DevZone\MinGW-4.3.1\bin\gfortran.exe -shared -o > ..\..\dll\libplplotf77d.dll CMakeFiles\plplotf77d.dir\strutil.obj > CMakeFiles\plplotf77d.dir\sfstubs.obj > CMakeFiles\plplotf77d.dir\configurable.obj ..\..\dll\libplplotf77cd.dll.a > ..\..\dll\libplplotd.dll.a ..\..\dll\libcsirocsa.dll.a > CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x54): undefined > reference to `_plsetopt7_' > CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x8c): undefined > reference to `_plabort7_' > CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0xc4): undefined > reference to `_plsdev7_' > CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0xe1): undefined > reference to `_plgdev7_' > CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x131): undefined > reference to `_plsfnam7_' > CMakeFiles\plplotf77d.dir\sfstubs.obj:sfstubs.f:(.text+0x14e): undefined > reference to `_plgfnam7_' > > >> >> For deeper analysis of the problem (as opposed to my guess above) do you >> have a tool that is equivalent of the Linux "nm" application to figure out >> symbols that are defined in libraries? If so, I suggest you look at the >> symbols in the C library being linked to by libplplotf77d.dll to see what >> form of plsetopt7 is defined. I suspect you will find plsetopt7_ is >> defined >> rather than _plsetopt7_ . > > I did that and attached it to the reply to Arjen. Could you send the nm output for libplplotf77cd as well? That library defines plsetopt7, but it may have the wrong underscoring convention or there may be some import/export of symbols problem. That library is mentioned in your detailed linking command above. Is the choice of library name and syntax of the command correct? Once you send us the nm results for libplplotf77cd we can compare how plsetopt7 is treated (which gave an error above) compared to plcol0 (which did not give a linking error). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Werner S. <sm...@ia...> - 2008-08-31 21:29:07
Attachments:
sfstubs.obj.nm.output
libplplotf77cd.dll.nm.output
|
> Could you send the nm output for libplplotf77cd as well? That library > defines plsetopt7, but it may have the wrong underscoring convention or > there may be some import/export of symbols problem. That library is > mentioned in your detailed linking command above. Is the choice of library > name and syntax of the command correct? > > Once you send us the nm results for libplplotf77cd we can compare how > plsetopt7 is treated (which gave an error above) compared to plcol0 (which > did not give a linking error). Hi Alan, attached is the nm output for libplplotf77cd.dll and sfstubs.obj, which causes the linking problems. I can't find the symbols in both outputs, but don't know if that is correct or not. I'll scan the internet a bit for such issues. Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Werner S. <sm...@ia...> - 2008-08-31 22:22:16
|
> Could you send the nm output for libplplotf77cd as well? That library > defines plsetopt7, but it may have the wrong underscoring convention or > there may be some import/export of symbols problem. That library is > mentioned in your detailed linking command above. Is the choice of library > name and syntax of the command correct? gfortran also allows to change how many underscores are added ( http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gfortran/Code-Gen-Options.html#Code-Gen-Options ) and in plstubs.h this can also be changed. But some tries didn't help anything and I don't know in which direction I should go, since the names show up in the library as well as in the object file which is linked to the library. Can't find anything useful in the internet so far. Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2008-08-31 23:50:13
|
On 2008-09-01 00:22+0200 Werner Smekal wrote: >> Could you send the nm output for libplplotf77cd as well? That library >> defines plsetopt7, but it may have the wrong underscoring convention or >> there may be some import/export of symbols problem. That library is >> mentioned in your detailed linking command above. Is the choice of >> library >> name and syntax of the command correct? > > gfortran also allows to change how many underscores are added ( > http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gfortran/Code-Gen-Options.html#Code-Gen-Options > ) and in plstubs.h this can also be changed. But some tries didn't help > anything and I don't know in which direction I should go, since the names > show up in the library as well as in the object file which is linked to the > library. Can't find anything useful in the internet so far. For what it is worth, here are the equivalent results on my (Debian testing) computer: software@raven> nm bindings/f77/libplplotf77cd.so |grep plsetopt7 000000000000a1fc T plsetopt7_ software@raven> nm bindings/f77/libplplotf77d.so |grep plsetopt7 U plsetopt7_ That is pretty clear. The symbol that not defined internally by libplplotf77d is supplied by libplplotf77cd where it is defined. Here is your equivalent result. irwin@raven> grep plsetopt7 *.output libplplotf77cd.dll.nm.output:100049c3 T _plsetopt7_ libplplotf77d.dll.nm.output:100049c3 T _plsetopt7_ sfstubs.obj.nm.output: U _plsetopt7_ The "U" for sfstubs.obj seems correct, but I frankly don't understand the "T" for libplplotf77d since that symbol is not defined internally in that library. However, I assume the libplplotf77cd results means that symbol is really defined there so I don't see why there is a linking issue. The only possibility I can think of to explain the bad linking error messages for MinGW is the symbols are not exported correctly for libplplotf77cd or not imported correctly for libplplotf77c. So it may be worthwhile to look carefully at how import/export of symbols is set up for MinGW. For example, I notice there is no mention of MinGW in pldll.h. I assume #if defined(WIN32) works for MinGW, but there is a very special list of compilers to check in that case, and I am wondering if e.g., __GNUC__ is defined for your particular version of MinGW. Perhaps it would be more reliable (or at least understandable) to have a special stanza for MinGW as in the Cygwin case? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Werner S. <sm...@ia...> - 2008-09-04 20:32:39
|
Hi Arjen, Arjen Markus wrote: > I have installed this new version of MinGW plus GCC, for some reason I > had to restart the download > a couple of times and I still have not succeeded in obtaining the make > utility. But I also noticed that there > does not seem to be a shell (at least not one I can get at via an icon > or an entry in the Start menu). Is there > a shell like bash or should I use a DOS window with an appropriate path? > > Regards, > > Arjen No, MinGW (official and unofficial) doesn't provide a bash like shell or something similar. I assume, that if you install (official) MSYS you will be asked, where the MinGW directory is, and that you can use MSYS also with the unofficial MinGW package. Otherwise just open the Windows CLI and set the paths correctly. I wrote some lines about that in the wiki: http://www.miscdebris.net/plplot_wiki/index.php?title=Setup_mingw section Setup. If this doesn't work, or is unclear, let me know, since I want people to easily be able to follow the instructions. Thanks for investing your time. Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Werner S. <sm...@ia...> - 2008-09-07 20:27:26
|
Hi, the email below was somehow never sent, since it stayed in my Drafts folder, so I send it again. Werner Ok, one step forward. The import library libplplotf77cd.dll.a (to which is linked to) doesn't contain any symbols. If I change in plstubs.h STUB_LAU to #define FNAME(x,y) PLDLLIMPEXP y##_ #define FNAME_(x,y) y##_ it's still not possible to link to libplplotf77cd.dll.a (although it contains symbols of the correct name - but it's possible to link directly to libplplotf77cd.dll if I make changes to the files produced by cmake. So it seems that for MinGW 4.x.x the functions are also not exported by default (as with Visual C++) - I thought that this is now possible but not default (there is some visibility flag which can be set). Maybe someone has some additional ideas. Werner Werner Smekal wrote: >> Could you send the nm output for libplplotf77cd as well? That library >> defines plsetopt7, but it may have the wrong underscoring convention or >> there may be some import/export of symbols problem. That library is >> mentioned in your detailed linking command above. Is the choice of library >> name and syntax of the command correct? > > gfortran also allows to change how many underscores are added ( > http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gfortran/Code-Gen-Options.html#Code-Gen-Options > ) and in plstubs.h this can also be changed. But some tries didn't help > anything and I don't know in which direction I should go, since the > names show up in the library as well as in the object file which is > linked to the library. Can't find anything useful in the internet so far. > > Werner > > -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2008-09-08 00:26:37
|
On 2008-09-07 22:27+0200 Werner Smekal wrote: > Hi, > > the email below was somehow never sent, since it stayed in my Drafts folder, > so I send it again. > > Werner > > Ok, > > one step forward. The import library libplplotf77cd.dll.a (to which is > linked to) doesn't contain any symbols. If I change in plstubs.h > STUB_LAU to > > #define FNAME(x,y) PLDLLIMPEXP y##_ > #define FNAME_(x,y) y##_ > > it's still not possible to link to libplplotf77cd.dll.a (although it > contains symbols of the correct name - but it's possible to link > directly to libplplotf77cd.dll if I make changes to the files produced > by cmake. So it seems that for MinGW 4.x.x the functions are also not > exported by default (as with Visual C++) - I thought that this is now > possible but not default (there is some visibility flag which can be set). > > Maybe someone has some additional ideas. Hi Werner: Is PLDLLIMPEXP defined properly for MinGW? From looking at include/pldll.h, I suspect it is not, although I may be missing something. Alan |
From: Arjen M. <arj...@wl...> - 2008-09-08 04:44:32
|
> Hi, > > the email below was somehow never sent, since it stayed in my Drafts > folder, so I send it again. > > Werner > > Ok, > > one step forward. The import library libplplotf77cd.dll.a (to which is > linked to) doesn't contain any symbols. If I change in plstubs.h > STUB_LAU to > > #define FNAME(x,y) PLDLLIMPEXP y##_ > #define FNAME_(x,y) y##_ > > it's still not possible to link to libplplotf77cd.dll.a (although it > contains symbols of the correct name - but it's possible to link > directly to libplplotf77cd.dll if I make changes to the files produced > by cmake. So it seems that for MinGW 4.x.x the functions are also not > exported by default (as with Visual C++) - I thought that this is now > possible but not default (there is some visibility flag which can be set). > > Maybe someone has some additional ideas. > Hi Werner, once I got it all working, I noticed the same thing: for some reason the import library (.dll.a) contains very few symbols. I have experimented a bit with STUB_LAU, but that has not solved much. The way forward is to write a small set of source files that mimick the set-up of PLplot - by then compiling/linking them manually I should be able to determine the correct incantation. But I come to the same conclusion: this version of GCC hides the symbols just like other Windows compilers. I am not sure I like that particular complication ;). Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2008-09-08 05:17:13
|
On 2008-09-08 06:44+0200 Arjen Markus wrote: >> Hi, >> >> the email below was somehow never sent, since it stayed in my Drafts >> folder, so I send it again. >> >> Werner >> >> Ok, >> >> one step forward. The import library libplplotf77cd.dll.a (to which is >> linked to) doesn't contain any symbols. If I change in plstubs.h >> STUB_LAU to >> >> #define FNAME(x,y) PLDLLIMPEXP y##_ >> #define FNAME_(x,y) y##_ >> >> it's still not possible to link to libplplotf77cd.dll.a (although it >> contains symbols of the correct name - but it's possible to link >> directly to libplplotf77cd.dll if I make changes to the files produced >> by cmake. So it seems that for MinGW 4.x.x the functions are also not >> exported by default (as with Visual C++) - I thought that this is now >> possible but not default (there is some visibility flag which can be set). >> >> Maybe someone has some additional ideas. >> > > Hi Werner, > > once I got it all working, I noticed the same thing: for some > reason the import library (.dll.a) contains very few symbols. > I have experimented a bit with STUB_LAU, but that has not solved > much. > > The way forward is to write a small set of source files that > mimick the set-up of PLplot - by then compiling/linking them > manually I should be able to determine the correct incantation. > > But I come to the same conclusion: this version of GCC hides > the symbols just like other Windows compilers. I am not sure > I like that particular complication ;). Also, please note that I have been working on gcc visibility issues recently so I may have inadvertently messed up the MinGW version of GCC case. The the PLplot trunk version right now, all is well for Linux gcc because I use the "(default)" case (i.e., everything visible) in plplot.h, but it is possible that logic is failing somehow for the MinGW/gcc case so you are not getting the "all symbols visible" result like you are supposed to with that "(default)" setting. As a nasty side note, when Andrew or I try "(hidden)" completely inexplicable results occur for the visibility of symbols in our core library with Linux/gcc. The majority of c_* symbols are visible, but some are not for unknown reasons which messes up everything else, and the list of those symbols which are invisible varies from my Debian Linux platform to Andrew's closely related Ubuntu Linux platform. (Huh??) In sum, something really strange seems to be going on with gcc visibility on Linux for the "(hidden)" case with PLDLLIMPEXP being ignored for some of our symbols but not others in a platform-dependent way. Something different but also strange may be going on with MinGW/gcc visibility even for the svn trunk "(default)" case. Thus, Werner and Arjen, as you debug visibility for the MinGW/gcc case, please keep us closely informed since there may be implications for Linux/gcc visibility. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2008-09-08 06:35:20
|
Alan W. Irwin wrote: > > Also, please note that I have been working on gcc visibility issues > recently > so I may have inadvertently messed up the MinGW version of GCC case. The > the PLplot trunk version right now, all is well for Linux gcc because > I use > the "(default)" case (i.e., everything visible) in plplot.h, but it is > possible that logic is failing somehow for the MinGW/gcc case so you are > not getting the "all symbols visible" result like you are supposed to > with > that "(default)" setting. > > As a nasty side note, when Andrew or I try "(hidden)" completely > inexplicable > results occur for the visibility of symbols in our core library with > Linux/gcc. The majority of c_* symbols are visible, but some are not for > unknown reasons which messes up everything else, and the list of those > symbols which are invisible varies from my Debian Linux platform to > Andrew's > closely related Ubuntu Linux platform. (Huh??) > > In sum, something really strange seems to be going on with gcc > visibility on > Linux for the "(hidden)" case with PLDLLIMPEXP being ignored for some > of our > symbols but not others in a platform-dependent way. Something > different but > also strange may be going on with MinGW/gcc visibility even for the svn > trunk "(default)" case. Thus, Werner and Arjen, as you debug > visibility for > the MinGW/gcc case, please keep us closely informed since there may be > implications for Linux/gcc visibility. > Hi Alan, I tried this with slightly older sources than your recent experiment. But given the issues with visibility that seem to exist in this MinGW case, I think the best way forward is indeed to test it on a set of small sources, so that we can isolate the causes or at least the various components. Regards, Arjen |