From: Jim D. <li...@di...> - 2007-01-06 03:45:20
|
Has anyone had success in building the shared library version on win32 using Visual Studio (or any compiler)--I encounter two problems. The first problem occurs if I do not build the static version first (-DBUILD_SHARED_LIBS=OFF) /out:..\..\dll\plplotf77d.dll /dll /STACK:10000000 /machine:I386 /debug /INCREMENTAL:YES "CMakeFiles\plplotf77d.dir\strutil.obj" "CMakeFiles\plplotf77d.dir\sfstubs.obj" "CMakeFiles\plplotf77d.dir\configurable.obj" -LIBPATH:c:\cygwin\opt\build\plplot_cmake_build\dll plplotf77cd.lib plplotd.lib gdi32.lib comdlg32.lib csirocsa.lib user32.lib LINK : fatal error LNK1104: cannot open file 'plplotf77cd.lib' If I look around for plplotf77cd.lib it does not exist. The second problem, which occurs if I build the static library first and then rerun cmake with -DBUILD_SHARED_LIBS=ON Microsoft (R) Incremental Linker Version 7.10.6030 Copyright (C) Microsoft Corporation. All rights reserved. /out:..\..\dll\plplotf77d.dll /dll /STACK:10000000 /machine:I386 /debug /INCREMENTAL:YES "CMakeFiles\plplotf77d.dir\strutil.obj" "CMakeFiles\plplotf77d.dir\sfstubs.obj" "CMakeFiles\plplotf77d.dir\configurable.obj" -LIBPATH:c:\cygwin\opt\build\plplot_cmake_build\dll plplotf77cd.lib plplotd.lib gdi32.lib comdlg32.lib csirocsa.lib user32.lib sfstubs.obj : error LNK2019: unresolved external symbol _PLSETOPT7 referenced in function _PLSETOPT sfstubs.obj : error LNK2019: unresolved external symbol _PLSDEV7 referenced in function _PLSDEV sfstubs.obj : error LNK2019: unresolved external symbol _PLGDEV7 referenced in function _PLGDEV sfstubs.obj : error LNK2019: unresolved external symbol _PLSFNAM7 referenced in function _PLSFNAM sfstubs.obj : error LNK2019: unresolved external symbol _PLGFNAM7 referenced in function _PLGFNAM sfstubs.obj : error LNK2019: unresolved external symbol _PLGVER7 referenced in function _PLGVER sfstubs.obj : error LNK2019: unresolved external symbol _PLAXES7 referenced in function _PLAXES sfstubs.obj : error LNK2019: unresolved external symbol _PLBOX7 referenced in function _PLBOX sfstubs.obj : error LNK2019: unresolved external symbol _PLBOX37 referenced in function _PLBOX3 sfstubs.obj : error LNK2019: unresolved external symbol _PLCON07 referenced in function _PLCON0 sfstubs.obj : error LNK2019: unresolved external symbol _PLCON17 referenced in function _PLCON1 sfstubs.obj : error LNK2019: unresolved external symbol _PLCON27 referenced in function _PLCON2 sfstubs.obj : error LNK2019: unresolved external symbol _PLCONT7 referenced in function _PLCONT sfstubs.obj : error LNK2019: unresolved external symbol _PLVEC07 referenced in function _PLVEC0 sfstubs.obj : error LNK2019: unresolved external symbol _PLVEC17 referenced in function _PLVEC1 sfstubs.obj : error LNK2019: unresolved external symbol _PLVEC27 referenced in function _PLVEC2 sfstubs.obj : error LNK2019: unresolved external symbol _PLVECT7 referenced in function _PLVECT sfstubs.obj : error LNK2019: unresolved external symbol _PLSHADE07 referenced in function _PLSHADE0 sfstubs.obj : error LNK2019: unresolved external symbol _PLSHADE17 referenced in function _PLSHADE1 sfstubs.obj : error LNK2019: unresolved external symbol _PLSHADE27 referenced in function _PLSHADE2 sfstubs.obj : error LNK2019: unresolved external symbol _PLSHADE7 referenced in function _PLSHADE sfstubs.obj : error LNK2019: unresolved external symbol _PLSHADES07 referenced in function _PLSHADES0 sfstubs.obj : error LNK2019: unresolved external symbol _PLSHADES17 referenced in function _PLSHADES1 sfstubs.obj : error LNK2019: unresolved external symbol _PLSHADES27 referenced in function _PLSHADES2 sfstubs.obj : error LNK2019: unresolved external symbol _PLSHADES7 referenced in function _PLSHADES sfstubs.obj : error LNK2019: unresolved external symbol _PLLAB7 referenced in function _PLLAB sfstubs.obj : error LNK2019: unresolved external symbol _PLMTEX7 referenced in function _PLMTEX sfstubs.obj : error LNK2019: unresolved external symbol _PLPTEX7 referenced in function _PLPTEX sfstubs.obj : error LNK2019: unresolved external symbol _PLSTART7 referenced in function _PLSTART sfstubs.obj : error LNK2019: unresolved external symbol _PLSETMAPFORMC referenced in function _PLMAP sfstubs.obj : error LNK2019: unresolved external symbol _PLMAPC referenced in function _PLMAP sfstubs.obj : error LNK2019: unresolved external symbol _PLMERIDIANSC referenced in function _PLMERIDIANS sfstubs.obj : error LNK2019: unresolved external symbol _PLSTRIPC7 referenced in function _PLSTRIPC configurable.obj : error LNK2019: unresolved external symbol _PLPARSEOPTS7 referenced in function _PLPARSEOPTS ..\..\dll\plplotf77d.dll : fatal error LNK1120: 34 unresolved externals |
From: Werner S. <sm...@ia...> - 2007-01-06 08:13:47
|
Hi Jim, the problem here is, that the fortran 77 bindings are not ready for being compiled to a dll with Visual C++. You can read former posts about that (regarding "DLL hell"). It works though with MinGW (therefor I works for me), since MinGW exports all symbols. To explain the problem in short: Visual C++ exports by default no function to a dll, which has not a special keyword in front of it (__declspec(export) or similar). Since no function in the f77 bindings has this keyword in front, no functions get exported. As a short workaround (until we made the bindings ready for "dll hell") change line 70 in plplot/bindings/f77/CMakeLists.txt to add_library(plplotf77c${LIB_TAG} static ${plplotf77c${LIB_TAG}_LIB_SRCS}) (add the word static). Then the f77 library will always be build as static and you shouldn't have any more problems for the moment. I'll try to change the code soon. HTH, Werner Jim Dishaw wrote: > Has anyone had success in building the shared library version on win32 > using Visual Studio (or any compiler)--I encounter two problems. The > first problem occurs if I do not build the static version first > (-DBUILD_SHARED_LIBS=OFF) > > /out:..\..\dll\plplotf77d.dll /dll /STACK:10000000 /machine:I386 /debug /INCREMENTAL:YES "CMakeFiles\plplotf77d.dir\strutil.obj" "CMakeFiles\plplotf77d.dir\sfstubs.obj" "CMakeFiles\plplotf77d.dir\configurable.obj" -LIBPATH:c:\cygwin\opt\build\plplot_cmake_build\dll plplotf77cd.lib plplotd.lib gdi32.lib comdlg32.lib csirocsa.lib user32.lib > LINK : fatal error LNK1104: cannot open file 'plplotf77cd.lib' > > If I look around for plplotf77cd.lib it does not exist. > > The second problem, which occurs if I build the static library first and > then rerun cmake with -DBUILD_SHARED_LIBS=ON > > Microsoft (R) Incremental Linker Version 7.10.6030 > Copyright (C) Microsoft Corporation. All rights reserved. > > /out:..\..\dll\plplotf77d.dll /dll /STACK:10000000 /machine:I386 /debug /INCREMENTAL:YES "CMakeFiles\plplotf77d.dir\strutil.obj" "CMakeFiles\plplotf77d.dir\sfstubs.obj" "CMakeFiles\plplotf77d.dir\configurable.obj" -LIBPATH:c:\cygwin\opt\build\plplot_cmake_build\dll plplotf77cd.lib plplotd.lib gdi32.lib comdlg32.lib csirocsa.lib user32.lib > sfstubs.obj : error LNK2019: unresolved external symbol _PLSETOPT7 referenced in function _PLSETOPT > sfstubs.obj : error LNK2019: unresolved external symbol _PLSDEV7 referenced in function _PLSDEV > sfstubs.obj : error LNK2019: unresolved external symbol _PLGDEV7 referenced in function _PLGDEV > sfstubs.obj : error LNK2019: unresolved external symbol _PLSFNAM7 referenced in function _PLSFNAM > sfstubs.obj : error LNK2019: unresolved external symbol _PLGFNAM7 referenced in function _PLGFNAM > sfstubs.obj : error LNK2019: unresolved external symbol _PLGVER7 referenced in function _PLGVER > sfstubs.obj : error LNK2019: unresolved external symbol _PLAXES7 referenced in function _PLAXES > sfstubs.obj : error LNK2019: unresolved external symbol _PLBOX7 referenced in function _PLBOX > sfstubs.obj : error LNK2019: unresolved external symbol _PLBOX37 referenced in function _PLBOX3 > sfstubs.obj : error LNK2019: unresolved external symbol _PLCON07 referenced in function _PLCON0 > sfstubs.obj : error LNK2019: unresolved external symbol _PLCON17 referenced in function _PLCON1 > sfstubs.obj : error LNK2019: unresolved external symbol _PLCON27 referenced in function _PLCON2 > sfstubs.obj : error LNK2019: unresolved external symbol _PLCONT7 referenced in function _PLCONT > sfstubs.obj : error LNK2019: unresolved external symbol _PLVEC07 referenced in function _PLVEC0 > sfstubs.obj : error LNK2019: unresolved external symbol _PLVEC17 referenced in function _PLVEC1 > sfstubs.obj : error LNK2019: unresolved external symbol _PLVEC27 referenced in function _PLVEC2 > sfstubs.obj : error LNK2019: unresolved external symbol _PLVECT7 referenced in function _PLVECT > sfstubs.obj : error LNK2019: unresolved external symbol _PLSHADE07 referenced in function _PLSHADE0 > sfstubs.obj : error LNK2019: unresolved external symbol _PLSHADE17 referenced in function _PLSHADE1 > sfstubs.obj : error LNK2019: unresolved external symbol _PLSHADE27 referenced in function _PLSHADE2 > sfstubs.obj : error LNK2019: unresolved external symbol _PLSHADE7 referenced in function _PLSHADE > sfstubs.obj : error LNK2019: unresolved external symbol _PLSHADES07 referenced in function _PLSHADES0 > sfstubs.obj : error LNK2019: unresolved external symbol _PLSHADES17 referenced in function _PLSHADES1 > sfstubs.obj : error LNK2019: unresolved external symbol _PLSHADES27 referenced in function _PLSHADES2 > sfstubs.obj : error LNK2019: unresolved external symbol _PLSHADES7 referenced in function _PLSHADES > sfstubs.obj : error LNK2019: unresolved external symbol _PLLAB7 referenced in function _PLLAB > sfstubs.obj : error LNK2019: unresolved external symbol _PLMTEX7 referenced in function _PLMTEX > sfstubs.obj : error LNK2019: unresolved external symbol _PLPTEX7 referenced in function _PLPTEX > sfstubs.obj : error LNK2019: unresolved external symbol _PLSTART7 referenced in function _PLSTART > sfstubs.obj : error LNK2019: unresolved external symbol _PLSETMAPFORMC referenced in function _PLMAP > sfstubs.obj : error LNK2019: unresolved external symbol _PLMAPC referenced in function _PLMAP > sfstubs.obj : error LNK2019: unresolved external symbol _PLMERIDIANSC referenced in function _PLMERIDIANS > sfstubs.obj : error LNK2019: unresolved external symbol _PLSTRIPC7 referenced in function _PLSTRIPC > configurable.obj : error LNK2019: unresolved external symbol _PLPARSEOPTS7 referenced in function _PLPARSEOPTS > ..\..\dll\plplotf77d.dll : fatal error LNK1120: 34 unresolved externals > > > > > ------------------------------------------------------------------------- > 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 > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dipl. Ing. 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...> - 2007-01-07 15:11:02
|
Hi Jim, could you test the latest source in cvs - I made the appropriate changes to the stubs files, but I don't know if the fortran compiler is than able to link to this library. Please remove the 'static' keyword again, as described in the last email - it should now work without that 'hack'. Let me know what the results are. Regards, Werner Jim Dishaw wrote: > Has anyone had success in building the shared library version on win32 > using Visual Studio (or any compiler)--I encounter two problems. The > first problem occurs if I do not build the static version first > (-DBUILD_SHARED_LIBS=OFF) [...] Dipl. Ing. 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...> - 2007-01-10 18:04:58
|
On 2007-01-10 08:36+0100 Arjen Markus wrote: > Hi, > > I tried to build the PLplot libraries statically. Here are my results: > > Cygwin/gcc+gfortran: > - The Fortran examples work perfectly, but I had to switch off > freetype support (see below) > - Some strange problem occurred with pltcl - missing symbols during > the linking phase. I have not looked into this issue yet > I rarely if ever test the combination of -DBUILD_TEST=ON -DBUILD_SHARED_LIBS=OFF on Linux, but your error report inspired me to try the combination, and it appears to work fine. Of course, python, java, and octave (which require a shared libraries build) were OFF, but both the build tree and install tree tests of c, c++, f77, and tcl were fine. I also specifically looked at some -dev png results in the install tree, and they looked fine indicating freetype support is working properly for Linux for a static PLplot build. > The freetype issue is weird: > - The executable expects "cygfreetype-6.dll" > - On my system I have "cygfreetype-9.dll" > > I have no clue where this discrepancy is coming from - the CMake files > do not contain any reference to any of these libraries. There is no mention of libfreetype.so.6.3.5 (the name of the library for Linux) in our CMake files, either. Instead, the only name mentioned is "freetype". CMake automatically prepends the prefix and appends the suffix to "freetype" that are appropriate for the library name on the particular platform (e.g., "lib" and ".so.6.3.5" for my platform). Since you have some inconsistency in the platform library name derived by CMake, my best guess is you did not start with an empty build tree so you have stale build information left over from a time when you had cygfreetype-6.dll installed. Alternatively, you have both cygfreetype-6.dll and cygfreetype-9.dll installed, but one or both of them is installed improperly (i.e., some of the required accompanying files/symlinks are missing). Anyhow, you have reported before that static libraries work on Cygwin, and my Linux experiments seem to indicate no new static library problems have been introduced for our CBS, so that is why I suspect there is some new problem specific to your system like I have suggested above. Please let us know the resolution of this newly introduced Cygwin static library problem once you have fixed it. > [out of order for clarity]Windows/MSVC 6.0+CVF: > - Building the library is no problem > - Building the Fortran examples fails - because of a conflict with > MSVCRTD.DLL > (conflicting versions of the runtime libraries - a well-known and > quite annoying > problem) Arjen, I don't have the expertise to interpret this error report. All I can tell is you are annoyed by something in the fortran examples build on your windows platform. Could you clarify please? For example, is this a bug we should fix in our CBS, a windows annoyance we should mention on the wiki because most window's developers will be unaware of it, or some window's annoyance that most windows developers will understand so there is no need to mention it? 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 Yorick front-end to PLplot (yplot.sf.net); 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...> - 2007-01-11 07:46:04
|
Alan W. Irwin wrote: >I rarely if ever test the combination of -DBUILD_TEST=ON >-DBUILD_SHARED_LIBS=OFF on Linux, but your error report inspired me to try >the combination, and it appears to work fine. Of course, >python, java, and octave (which require a shared libraries build) were OFF, >but both the build tree and install tree tests of c, c++, f77, and tcl were >fine. I also specifically looked at some -dev png results in the install >tree, and they looked fine indicating freetype support is working properly >for Linux for a static PLplot build. > > Good, I am glad this is working okay for Linux. My problem with freetype may be entirely due to the Cygwin installation on my machine. > > >>The freetype issue is weird: >>- The executable expects "cygfreetype-6.dll" >>- On my system I have "cygfreetype-9.dll" >> >>I have no clue where this discrepancy is coming from - the CMake files >>do not contain any reference to any of these libraries. >> >> > >There is no mention of libfreetype.so.6.3.5 (the name of the library for >Linux) in our CMake files, either. Instead, the only name mentioned is >"freetype". CMake automatically prepends the prefix and appends the suffix >to "freetype" that are appropriate for the library name on the particular >platform (e.g., "lib" and ".so.6.3.5" for my platform). > >Since you have some inconsistency in the platform library name derived by >CMake, my best guess is you did not start with an empty build tree so you >have stale build information left over from a time when you had >cygfreetype-6.dll installed. Alternatively, you have both cygfreetype-6.dll >and cygfreetype-9.dll installed, but one or both of them is installed >improperly (i.e., some of the required accompanying files/symlinks are >missing). > > No, I always start with a completely fresh build directory (well, I throw away all files in an existing directory and then run CMake, but that should have the same result). >Anyhow, you have reported before that static libraries work on Cygwin, and >my Linux experiments seem to indicate no new static library problems have >been introduced for our CBS, so that is why I suspect there is some new >problem specific to your system like I have suggested above. > >Please let us know the resolution of this newly introduced Cygwin static >library problem once you have fixed it. > > Will do. It will require some digging into the freetype installation in my Cygwin environment - that must be the cause of this strange confusion. I checked the entire directory structure: there is only one file matching cygfreetype*.dll and that is cygfreetype-9.dll. > > >>[out of order for clarity]Windows/MSVC 6.0+CVF: >>- Building the library is no problem >>- Building the Fortran examples fails - because of a conflict with >>MSVCRTD.DLL >> (conflicting versions of the runtime libraries - a well-known and >>quite annoying >> problem) >> >> > >Arjen, I don't have the expertise to interpret this error report. All I can >tell is you are annoyed by something in the fortran examples build on your >windows platform. Could you clarify please? For example, is this a bug we >should fix in our CBS, a windows annoyance we should mention on the wiki >because most window's developers will be unaware of it, or some window's >annoyance that most windows developers will understand so there is no need >to mention it? > > Jim already fixed it. I am sorry that some deep personal frustration has crept into the above ... Let me try to explain: On Windows compilers incorporate information about the runtime library that is to be used in the object files. Different runtime libraries are used for different global options: debugging, multithreading, ... When the linker gathers all these object files together, it also reads this information to get the correct runtime libraries. But if compiler options (especially from different compilers - in our case the C and the Fortran compiler) cause different runtime libraries to be specified, there can be a conflict. This frequently leads to error messages such as "library X: some symbol already defined in library Y". The annoying part (and that is where my frustration comes from) is that it is often unclear what you should do about it and sometimes it appears that there is no other solution than _force_ the linker to produce output. I will submit (an edited version of) this text to the Wiki, because people may well run into this. Regards, Arjen |
From: Jim D. <li...@di...> - 2007-01-10 20:55:54
|
Arjen Markus <arj...@wl...> writes: > Windows/MSVC 6.0+CVF: > - Building the library is no problem > - Building the Fortran examples fails - because of a conflict with > MSVCRTD.DLL > (conflicting versions of the runtime libraries - a well-known and > quite annoying > problem) > Something is not quite right with using the Visual Studio compiler and the CMake build of plplot. I can build and successfully use plplot on win32 with the VS compiler if I use the sys/win32/msdev build method. I've made some changes to bindings/f77/CMakeLists.txt, bindings/f77/plstubs.h, cmake/modules/fortran.cmake, and cmake/modules/summary.cmake that will fix the linkage issue on win32/Visual Studio. For static libraries, we should be building with the /Zl option and not /MD (or /MDd, /ML, /MLd, /MT, or /MTd) which omits the default library name in the .OBJ file. That will produce a library that will not cause run-time library conflict. |
From: Arjen M. <arj...@wl...> - 2007-01-11 07:35:22
|
Jim Dishaw wrote: >Something is not quite right with using the Visual Studio compiler >and the CMake build of plplot. I can build and successfully use >plplot on win32 with the VS compiler if I use the sys/win32/msdev >build method. > >I've made some changes to bindings/f77/CMakeLists.txt, >bindings/f77/plstubs.h, cmake/modules/fortran.cmake, and >cmake/modules/summary.cmake that will fix the linkage issue on >win32/Visual Studio. > >For static libraries, we should be building with the /Zl option and not >/MD (or /MDd, /ML, /MLd, /MT, or /MTd) which omits the default library >name in the .OBJ file. That will produce a library that will not cause >run-time library conflict. > > Great! I was contemplating adding the /force option (for CVF) so that errors concerning duplicate symbols are ignored, but this looks like a much better solution. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2007-01-11 18:41:23
|
On 2007-01-11 08:45+0100 Arjen Markus wrote: > I checked the entire directory structure: there is only one file matching > cygfreetype*.dll > and that is cygfreetype-9.dll. Hi Arjen: One way cygfreetype-6.dll could still be interfering is if one of the system libraries required by PLplot is out of date so that it is linked to cygfreetype-6.dll rather than cygfreetype-9.dll. The freetype library is linked by a lot of different system libraries so the potential for such inconsistencies is high. I am not familiar with Cygwin but the Debian analogy I am using here is if some Debian user was attempting to use a mixture of Debian stable and unstable they would run into trouble because of library version inconsistencies. Anyhow, an upgrade to a self-consistent version of Cygwin may be the solution in your 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 Yorick front-end to PLplot (yplot.sf.net); 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...> - 2007-01-15 07:33:04
|
Alan W. Irwin wrote: >On 2007-01-11 08:45+0100 Arjen Markus wrote: > > > >>I checked the entire directory structure: there is only one file matching >>cygfreetype*.dll >>and that is cygfreetype-9.dll. >> >> > >Hi Arjen: > >One way cygfreetype-6.dll could still be interfering is if one of the system >libraries required by PLplot is out of date so that it is linked to >cygfreetype-6.dll rather than cygfreetype-9.dll. The freetype library is >linked by a lot of different system libraries so the potential for such >inconsistencies is high. > >I am not familiar with Cygwin but the Debian analogy I am using here is if >some Debian user was attempting to use a mixture of Debian stable and >unstable they would run into trouble because of library version >inconsistencies. > >Anyhow, an upgrade to a self-consistent version of Cygwin may be the >solution in your case. > > > Hi Alan, this was my mistake: I said entire directory structure, but I should have said entire directory structure under c:/cygwin/lib. It so happens that there is a cygfreetype-6.dll in the c:/cygwin/bin directory. However, there does appear to be a conflict: - cygfreetype-9.dll resides in the lib/X11R6 directory that contains a few DLLs that are needed for PLplot under Cygwin - when I tried the examples with the default path (that includes /usr/bin) it did not work - when I added /usr/lib/X11R6 it still did not work - when I removed the freetype support, the examples finally started properly and I got the pictures I expected I have not tried with a clean slate yet - hopefully this will solve the issue Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2007-01-10 07:36:35
|
Hi, I tried to build the PLplot libraries statically. Here are my results: Cygwin/gcc+gfortran: - The Fortran examples work perfectly, but I had to switch off freetype support (see below) - Some strange problem occurred with pltcl - missing symbols during the linking phase. I have not looked into this issue yet Windows/MSVC 6.0+CVF: - Building the library is no problem - Building the Fortran examples fails - because of a conflict with MSVCRTD.DLL (conflicting versions of the runtime libraries - a well-known and quite annoying problem) The freetype issue is weird: - The executable expects "cygfreetype-6.dll" - On my system I have "cygfreetype-9.dll" I have no clue where this discrepancy is coming from - the CMake files do not contain any reference to any of these libraries. Regards, Arjen |