From: Orion P. <or...@co...> - 2011-11-22 23:00:30
|
In my Fedora packages, the various language binding libraries are linked as follows: # ldd /usr/lib/libplplotcxxd.so linux-gate.so.1 => (0x00fbe000) libplplotd.so.11 => /usr/lib/libplplotd.so.11 (0x48cb0000) libltdl.so.7 => /usr/lib/libltdl.so.7 (0x499d1000) libdl.so.2 => /lib/libdl.so.2 (0x4704f000) libcsirocsa.so.0 => /usr/lib/libcsirocsa.so.0 (0x47913000) libcsironn.so.0 => /usr/lib/libcsironn.so.0 (0x47901000) libqhull.so.5 => /usr/lib/libqhull.so.5 (0x478aa000) libqsastime.so.0 => /usr/lib/libqsastime.so.0 (0x4790b000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x47a01000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x470dd000) libm.so.6 => /lib/libm.so.6 (0x47022000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x47073000) libc.so.6 => /lib/libc.so.6 (0x46e75000) /lib/ld-linux.so.2 (0x46e50000) This generates the following rpmlint warnings: plplot-libs.i686: W: unused-direct-shlib-dependency /usr/lib/libplplotcxxd.so.10.0.0 /usr/lib/libltdl.so.7 plplot-libs.i686: W: unused-direct-shlib-dependency /usr/lib/libplplotcxxd.so.10.0.0 /lib/libdl.so.2 plplot-libs.i686: W: unused-direct-shlib-dependency /usr/lib/libplplotcxxd.so.10.0.0 /usr/lib/libcsirocsa.so.0 plplot-libs.i686: W: unused-direct-shlib-dependency /usr/lib/libplplotcxxd.so.10.0.0 /usr/lib/libcsironn.so.0 plplot-libs.i686: W: unused-direct-shlib-dependency /usr/lib/libplplotcxxd.so.10.0.0 /usr/lib/libqhull.so.5 plplot-libs.i686: W: unused-direct-shlib-dependency /usr/lib/libplplotcxxd.so.10.0.0 /usr/lib/libqsastime.so.0 plplot-libs.i686: W: unused-direct-shlib-dependency /usr/lib/libplplotcxxd.so.10.0.0 /usr/lib/libfreetype.so.6 plplot-libs.i686: W: unused-direct-shlib-dependency /usr/lib/libplplotcxxd.so.10.0.0 /lib/libm.so.6 plplot-libs.i686: W: unused-direct-shlib-dependency /usr/lib/libplplotcxxd.so.10.0.0 /lib/libgcc_s.so.1 because the code in libplplotcxxd.so does not use any of those libraries, it does not need to be linked to them, only to libplplotd. Likewise: # pkg-config plplotd --libs -lplplotd -lltdl -ldl -lm -lcsirocsa -lcsironn -lqhull -lqsastime -lfreetype Is incorrect, it only needs to list -lplplotd. The other libraries are only needed for static linking, which can be obtained with: # pkg-config plplotd --libs --static -lplplotd -lltdl -ldl -lm -lcsirocsa -lcsironn -lqhull -lqsastime -lfreetype Can this be tackled? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Alan W. I. <ir...@be...> - 2011-11-23 09:35:44
|
Hi Orion: Thanks for reporting this issue. More below. On 2011-11-22 16:00-0700 Orion Poplawski wrote: > In my Fedora packages, the various language binding libraries are linked as > follows: > > # ldd /usr/lib/libplplotcxxd.so > linux-gate.so.1 => (0x00fbe000) > libplplotd.so.11 => /usr/lib/libplplotd.so.11 (0x48cb0000) > libltdl.so.7 => /usr/lib/libltdl.so.7 (0x499d1000) > libdl.so.2 => /lib/libdl.so.2 (0x4704f000) > libcsirocsa.so.0 => /usr/lib/libcsirocsa.so.0 (0x47913000) > libcsironn.so.0 => /usr/lib/libcsironn.so.0 (0x47901000) > libqhull.so.5 => /usr/lib/libqhull.so.5 (0x478aa000) > libqsastime.so.0 => /usr/lib/libqsastime.so.0 (0x4790b000) > libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x47a01000) > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x470dd000) > libm.so.6 => /lib/libm.so.6 (0x47022000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x47073000) > libc.so.6 => /lib/libc.so.6 (0x46e75000) > /lib/ld-linux.so.2 (0x46e50000) ldd without any options just lists all direct and indirect links which doesn't tell you anything about overlinking. Instead, use the -u option, e.g., software@raven> ldd -u bindings/c++/libplplotcxxd.so Unused direct dependencies: /usr/lib/libltdl.so.7 /lib/libdl.so.2 /home/software/plplot_svn/HEAD/build_dir/lib/csa/libcsirocsa.so.0 /home/software/plplot_svn/HEAD/build_dir/lib/nn/libcsironn.so.0 /home/software/qhull/install/lib/libqhull.so.5 /home/software/plplot_svn/HEAD/build_dir/lib/qsastime/libqsastime.so.0 /usr/lib/libfreetype.so.6 /lib/libm.so.6 /lib/libgcc_s.so.1 This result agrees exactly with what rpmlint says below about the 9 libraries that are linked by our build system to libplplotcxxd.so when they don't have to be. And I assume overlinking is also an issue for most or all of our other libraries as well. > > This generates the following rpmlint warnings: > > plplot-libs.i686: W: unused-direct-shlib-dependency > /usr/lib/libplplotcxxd.so.10.0.0 /usr/lib/libltdl.so.7 > plplot-libs.i686: W: unused-direct-shlib-dependency > /usr/lib/libplplotcxxd.so.10.0.0 /lib/libdl.so.2 > plplot-libs.i686: W: unused-direct-shlib-dependency > /usr/lib/libplplotcxxd.so.10.0.0 /usr/lib/libcsirocsa.so.0 > plplot-libs.i686: W: unused-direct-shlib-dependency > /usr/lib/libplplotcxxd.so.10.0.0 /usr/lib/libcsironn.so.0 > plplot-libs.i686: W: unused-direct-shlib-dependency > /usr/lib/libplplotcxxd.so.10.0.0 /usr/lib/libqhull.so.5 > plplot-libs.i686: W: unused-direct-shlib-dependency > /usr/lib/libplplotcxxd.so.10.0.0 /usr/lib/libqsastime.so.0 > plplot-libs.i686: W: unused-direct-shlib-dependency > /usr/lib/libplplotcxxd.so.10.0.0 /usr/lib/libfreetype.so.6 > plplot-libs.i686: W: unused-direct-shlib-dependency > /usr/lib/libplplotcxxd.so.10.0.0 /lib/libm.so.6 > plplot-libs.i686: W: unused-direct-shlib-dependency > /usr/lib/libplplotcxxd.so.10.0.0 /lib/libgcc_s.so.1 > > [....]Can this be tackled? We link libplplotcxx with CMake as follows in our build system: target_link_libraries(plplotcxx${LIB_TAG} plplot${LIB_TAG}) In other words, we only mention the direct link to CMake. However, by default CMake uses transative linking (search for "transitive" in the CMake man page). That is, the generated link line for libplplotcxxd not only includes libplplotd, but also all of the libraries linked by libplplotd, all libraries linked by libplplotd dependencies, etc. We currently use that CMake default so that is why the above 9 unused direct dependencies are generated. >From a test I did (see details in my recent post to the CMake list) it appears there is a way to drop transitive linking with CMake. But I will wait for replies to that post before trying to supply an experimental option (which would default to OFF) with the PLplot build system to disable transitive linking. I would appreciate you testing that experimental option once I implement it. Meanwhile, could you give me a complete list of PLplot libraries which generate the rpmlint warnings about unused direct dependencies? 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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: Orion P. <or...@co...> - 2011-11-23 15:49:17
Attachments:
unused
|
On 11/23/2011 02:35 AM, Alan W. Irwin wrote: > Hi Orion: > > Thanks for reporting this issue. More below. > > On 2011-11-22 16:00-0700 Orion Poplawski wrote: > > > ldd without any options just lists all direct and indirect links > which doesn't tell you anything about overlinking. > > Instead, use the -u option Thanks for that, must be what rpmlint uses. > > We link libplplotcxx with CMake as follows in our build system: > > target_link_libraries(plplotcxx${LIB_TAG} plplot${LIB_TAG}) > > In other words, we only mention the direct link to CMake. However, by > default CMake uses transative linking (search for "transitive" in the > CMake man page). That is, the generated link line for libplplotcxxd > not only includes libplplotd, but also all of the libraries linked by > libplplotd, all libraries linked by libplplotd dependencies, etc. We > currently use that CMake default so that is why the above 9 unused > direct dependencies are generated. > >> From a test I did (see details in my recent post to the CMake list) it > appears there is a way to drop transitive linking with CMake. But I > will wait for replies to that post before trying to supply an > experimental option (which would default to OFF) with the PLplot build > system to disable transitive linking. I would appreciate you testing > that experimental option once I implement it. I was trying to remember where/what I had seen on the subject recently. I can certainly test whatever changes you make. > Meanwhile, could you give me a complete list of PLplot libraries which > generate the rpmlint warnings about unused direct dependencies? Attached. Don't forget about the pkg-config issue as well. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Alan W. I. <ir...@be...> - 2011-11-23 20:06:18
|
On 2011-11-23 08:48-0700 Orion Poplawski wrote: >> Meanwhile, could you give me a complete list of PLplot libraries which >> generate the rpmlint warnings about unused direct dependencies? > > Attached. Hi Orion: Thanks for that. I was concerned that rpmlint would complain about our driver plugins, but apparently the only concern is our principal libraries. > > Don't forget about the pkg-config issue as well. > The pkg-config man page gives the reason why we get transitive linking in that case: Requires: This is a comma-separated list of packages that are required by your package. Flags from dependent packages will be merged in to the flags reported for your package.... The solution I am investigating for CMake automatically disables transitive linking for the shared case but uses transitive linking for the static case (which I believe is necessary from the accompanying discusssion). So we will want to do the same for the pkg-config case. From reading further in the pkg-config man page it appears you would get that by replacing the Requires: line in our *.pc files by the corresponding Requires.private: line. That is, for plplotd-c++.pc change Requires: plplotd ==> Requires.private: plplotd and similarly for our other *.pc files. Could you try that plplotd-c++.pc change by hand (or by editing bindings/c++/CMakeLists.txt) to see if that satisfies your pkg-config need for libplplotcxxd while I am working on the other question of dropping transitive linking from our CMake-generated linking? 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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: Orion P. <or...@co...> - 2011-11-23 23:53:34
|
On 11/23/2011 01:06 PM, Alan W. Irwin wrote: > On 2011-11-23 08:48-0700 Orion Poplawski wrote: > >> Don't forget about the pkg-config issue as well. >> > > The pkg-config man page gives the reason why we get transitive linking > in that case: > > Requires: > This is a comma-separated list of packages that are required by > your package. Flags from dependent packages will be merged in to > the flags reported for your package.... > > The solution I am investigating for CMake automatically disables > transitive linking for the shared case but uses transitive linking for > the static case (which I believe is necessary from the accompanying > discusssion). So we will want to do the same for the pkg-config > case. From reading further in the pkg-config man page it appears you > would get that by replacing the Requires: line in our *.pc files by > the corresponding Requires.private: line. That is, for plplotd-c++.pc > change > > Requires: plplotd > ==> > Requires.private: plplotd > > and similarly for our other *.pc files. > > Could you try that plplotd-c++.pc change by hand (or by editing > bindings/c++/CMakeLists.txt) to see if that satisfies your pkg-config > need for libplplotcxxd while I am working on the other question of > dropping transitive linking from our CMake-generated linking? I'm testing the following change: diff -up plplot-5.9.9/pkgcfg/plplot-template.pc.cmake.pkgconfig plplot-5.9.9/pkgcfg/plplot-template.pc.cmake --- plplot-5.9.9/pkgcfg/plplot-template.pc.cmake.pkgconfig 2011-10-12 18:43:01.000000000 -0600 +++ plplot-5.9.9/pkgcfg/plplot-template.pc.cmake 2011-11-23 16:47:14.627158764 -0700 @@ -4,7 +4,7 @@ drvdir=@LIB_DIR@/plplot@VERSION@/drivers Name: PLplot @PC_SHORT_NAME@ Description: Scientific plotting library (@PC_LONG_NAME@@PC_PRECISION@ precision) -Requires: @PC_REQUIRES@ +Requires.private: @PC_REQUIRES@ Version: @VERSION@ Libs: -L${libdir} @PC_LINK_FLAGS@ Cflags: -I${includedir} @PC_COMPILE_FLAGS@ Which hopefully handles most/all in one swoop. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Orion P. <or...@co...> - 2011-11-24 00:49:42
|
On 11/23/2011 04:52 PM, Orion Poplawski wrote: > On 11/23/2011 01:06 PM, Alan W. Irwin wrote: >> On 2011-11-23 08:48-0700 Orion Poplawski wrote: >> >>> Don't forget about the pkg-config issue as well. >>> >> >> The pkg-config man page gives the reason why we get transitive linking >> in that case: >> >> Requires: >> This is a comma-separated list of packages that are required by >> your package. Flags from dependent packages will be merged in to >> the flags reported for your package.... >> >> The solution I am investigating for CMake automatically disables >> transitive linking for the shared case but uses transitive linking for >> the static case (which I believe is necessary from the accompanying >> discusssion). So we will want to do the same for the pkg-config >> case. From reading further in the pkg-config man page it appears you >> would get that by replacing the Requires: line in our *.pc files by >> the corresponding Requires.private: line. That is, for plplotd-c++.pc >> change >> >> Requires: plplotd >> ==> >> Requires.private: plplotd >> >> and similarly for our other *.pc files. >> >> Could you try that plplotd-c++.pc change by hand (or by editing >> bindings/c++/CMakeLists.txt) to see if that satisfies your pkg-config >> need for libplplotcxxd while I am working on the other question of >> dropping transitive linking from our CMake-generated linking? > > I'm testing the following change: > > diff -up plplot-5.9.9/pkgcfg/plplot-template.pc.cmake.pkgconfig > plplot-5.9.9/pkgcfg/plplot-template.pc.cmake > --- plplot-5.9.9/pkgcfg/plplot-template.pc.cmake.pkgconfig 2011-10-12 > 18:43:01.000000000 -0600 > +++ plplot-5.9.9/pkgcfg/plplot-template.pc.cmake 2011-11-23 > 16:47:14.627158764 -0700 > @@ -4,7 +4,7 @@ drvdir=@LIB_DIR@/plplot@VERSION@/drivers > > Name: PLplot @PC_SHORT_NAME@ > Description: Scientific plotting library (@PC_LONG_NAME@@PC_PRECISION@ > precision) > -Requires: @PC_REQUIRES@ > +Requires.private: @PC_REQUIRES@ > Version: @VERSION@ > Libs: -L${libdir} @PC_LINK_FLAGS@ > Cflags: -I${includedir} @PC_COMPILE_FLAGS@ > > Which hopefully handles most/all in one swoop. > Test building the examples with this change I get: /usr/bin/gnatmake -aI/usr/share/ada/adainclude/plplotadad -aL/usr/lib/ada/adalib/plplotadad x15a.adb \ -cargs `PKG_CONFIG_PATH=/usr/lib/pkgconfig pkg-config --cflags plplotd-ada` -largs `PKG_CONFIG_PATH=/usr/lib/pkgconfig pkg-config --libs plplotd-ada` gcc -c -I/usr/share/ada/adainclude/plplotadad -I/usr/include/plplot x15a.adb gnatbind -aI/usr/share/ada/adainclude/plplotadad -aO/usr/lib/ada/adalib/plplotadad -x x15a.ali gnatlink x15a.ali -lplplotadad /usr/bin/ld: ./x15a.o: undefined reference to symbol 'c_plfill' /usr/bin/ld: note: 'c_plfill' is defined in DSO /usr/lib/libplplotd.so.11 so try adding it to the linker command line /usr/lib/libplplotd.so.11: could not read symbols: Invalid operation collect2: ld returned 1 exit status gnatlink: error when calling /usr/bin/gcc gnatmake: *** link failed. So something in the ada bindings can require (but not always) linking against plplotd. Others: /usr/lib/ccache/c++ x17.cc -o x17 `pkg-config --cflags --libs plplotd-c++` /usr/bin/ld: /tmp/ccUpkDBH.o: undefined reference to symbol 'c_plrandd' /usr/bin/ld: note: 'c_plrandd' is defined in DSO /usr/lib/libplplotd.so.11 so try adding it to the linker command line /usr/lib/libplplotd.so.11: could not read symbols: Invalid operation So I think it is probably worth it to keep plplotd in the Requires, but perhaps move the others items out of the plplotd.pc Requires. Here's an odd one: make[1]: Entering directory `/usr/share/plplot5.9.9/examples/f77' /usr/bin/gfortran x01f.f -o x01f `pkg-config --cflags --libs plplotd-f77` x01f.f:29: Error: Can't open included file 'plplot_parameters.h' make[1]: *** [x01f] Error 1 Apparently with gfortran you must explicitly add -I/usr/include. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Andrew R. <and...@us...> - 2011-11-25 21:57:07
|
On Thu, Nov 24, 2011 at 06:04:02PM -0800, Alan Irwin wrote: > On 2011-11-24 12:11-0800 Alan W. Irwin wrote: > > > I will now move on [from C and C++] to other languages to see how far I can get with > > non-transitive linking. > > As of revision 12045 I have gotten pretty far. I have completed a > NON_TRANSITIVE implementation (both for CMake and our *.pc files used > for pkg-config) for most of the libraries that generated rpmlint > messages for Orion as well as libplplotdmd. Everything tests without > issues on Debian stable, but there are very likely still issues on > more modern distros such as Debian unstable and Fedora that others > will have to work out. Also, see my recent commit messages for > further pkg-config changes that I suggest if anybody has interest in > implementing those. Also consult the commit message for the > libplplotdmd NON_TRANSITIVE implementation which is a really special > case that I cannot test because of a bad implementation of D shared > libraries in Debian stable. > > My remaining ToDo list for this project is to complete Orion's list of > libraries (i.e., do the NON_TRANSITIVE implementation for > libplplotwxwidgetsd and libplplotqtd); fix the now broken static build > (by adding the --static option to pkg-config in that case) for the > traditional installed examples tree; and do a comprehensive test with > -DNON_TRANSITIVE=ON to fill in any tests that were missed by my > limited and piece-meal testing of my NON_TRANSITIVE changes as I went > along. Alan, The fortran 77 and fortran 95 examples did not compile as you need to explicitly link against libplplotf77cd and libplplotf95cd respectively. Parts of the fortran bindings are implemented in C and so the C parts of the library need to be directly linked. Now fixed in svn. Examples also build fine using pkg-config in the install tree. Ada also doesn't work, although the situation is more complicated. I don't understand enough about ada, but it appears that building the examples is linking in the .o files from bindings/ada/CMakeFiles/plplotadad.dir/ and these reference C API functions. This seems odd to me so I don't know whether it is a "bug" or a feature. At the moment it looks like libplplotd would need to be explicitly linked in. I can't see how to do this though. The gnat manpages are brief to say the least... I know there are some "issues" with gnat in Debian unstable so it is possible this is a compiler bug. Orion, can you confirm the problem? For reference the relevant build error message is --------------- Linking Ada executable x01a gnatbind -aI/home/andrew/software/plplot/plplot/examples/ada -aI/home/andrew/software/plplot/plplot/bindings/ada -aO/home/andrew/software/plplot/build_test/bindings/ada/CMakeFiles/plplotadad.dir -x x01a.ali gnatlink x01a.ali -rdynamic ../../bindings/ada/libplplotadad.so.0.0.0 -Wl,-rpath,/home/andrew/software/plplot/build_test/bindings/ada:/home/andrew/software/plplot/build_test/src:/home/andrew/software/plplot/build_test/lib/csa:/home/andrew/software/plplot/build_test/lib/qsastime -Wl,-rpath-link,/home/andrew/software/plplot/build_test/src:/home/andrew/software/plplot/build_test/lib/csa:/home/andrew/software/plplot/build_test/lib/qsastime /usr/bin/ld: /home/andrew/software/plplot/build_test/bindings/ada/CMakeFiles/plplotadad.dir/plplot_traditional.o: undefined reference to symbol 'c_plspause' /usr/bin/ld: note: 'c_plspause' is defined in DSO /home/andrew/software/plplot/build_test/src/libplplotd.so.11 so try adding it to the linker command line /home/andrew/software/plplot/build_test/src/libplplotd.so.11: could not read symbols: Invalid operation collect2: ld returned 1 exit status gnatlink: error when calling /usr/bin/gcc-4.6 gnatmake: *** link failed. make[2]: *** [examples/ada/x01a] Error 4 make[1]: *** [examples/ada/CMakeFiles/x01a.dir/all] Error 2 ---------------- Incidentally gdc works fine. Andrew |
From: Orion P. <or...@co...> - 2011-11-30 05:24:46
|
On 11/29/2011 07:05 PM, Alan W. Irwin wrote: >> Fatal Error: Can't open module file 'plf95demolib.mod' for reading at >> (1): No such file or directory >> >> This file does not appear to have been installed. > > Oops. I forgot to do an svn update to bring in Arjen's f95 changes > before I did my comprehensive test. Revision 12071 should fix this > (and other) issues with those f95 changes. One question, why is libplf95demolib.a made, not libplf95demolib.so? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Arjen M. <arj...@de...> - 2011-11-30 07:42:14
|
Hi Orion, I introduced this library to be able to use more Fortran 95 features than we had before in the examples. I am not sure what the best way is to build this library - I suppose it can be a shared object if PLplot is built as a setof shared objects. In any case, its current state does not represent a very sophisticated design choice. Regards, Arjen On 2011-11-30 06:24, Orion Poplawski wrote: > On 11/29/2011 07:05 PM, Alan W. Irwin wrote: >>> Fatal Error: Can't open module file 'plf95demolib.mod' for reading at >>> (1): No such file or directory >>> >>> This file does not appear to have been installed. >> Oops. I forgot to do an svn update to bring in Arjen's f95 changes >> before I did my comprehensive test. Revision 12071 should fix this >> (and other) issues with those f95 changes. > > One question, why is libplf95demolib.a made, not libplf95demolib.so? > > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Orion P. <or...@co...> - 2011-11-30 14:25:03
|
On 11/30/2011 12:41 AM, Arjen Markus wrote: > Hi Orion, > > I introduced this library to be able to use more Fortran 95 features > than we had before in the examples. I am not sure what the best way > is to build this library - I suppose it can be a shared object if > PLplot is built as a setof shared objects. In any case, its current > state does not represent a very sophisticated design choice. Actually, I don't have a big opinion on it, but I do think that the mod and library should get installed into the examples/f95 directory instead of the main system locations. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Alan W. I. <ir...@be...> - 2011-11-24 18:17:51
|
On 2011-11-24 14:24-0000 Andrew Ross wrote: >>> Apparently that error is caught on Fedora but not Debian stable for >>> reasons I don't understand. I wonder if it is also caught on >>> Debian testing, recent Ubuntu, etc., i.e., I wonder if Debian stable >>> is out of step with modern distributions in this regard. >> >> I haven't had chance yet, but I will try your patch to see if it reduces >> the warnings / generates any errors for the current plplot packages on >> debian unstable. > > With Ubunutu 10.04 LTS (from last year) example 17 compiles fine with > -DNON_TRANSITIVE=ON. With the latest Debian unstable I get the same > error as Orion. This is clearly a feature of a stricter new version of > the linker. Seems a good thing to me. > Hi Andrew: Thanks for that confirmation of the distro-related change that I had hypothesized. As a general rule it is always a mistake to encourage errors (such as incorrect direct linking) by attempting to work around the error in advance. So I strongly agree that the very latest Linux distros (e.g. Debian unstable and Fedora) are doing the right thing here by deploying a stricter linker. Better late than never! I am going to leave it to you to correct x17.cc in case there are more issues Debian unstable detects with the C++ examples. Today, I plan to expand use of NON_TRANSITIVE to languages other than C++. I will start with C (i.e., libplplotd + all the libraries in lib). 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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: Andrew R. <and...@us...> - 2011-11-24 20:29:57
|
On Thu, Nov 24, 2011 at 10:17:42AM -0800, Alan Irwin wrote: > On 2011-11-24 14:24-0000 Andrew Ross wrote: > > > With Ubunutu 10.04 LTS (from last year) example 17 compiles fine with > > -DNON_TRANSITIVE=ON. With the latest Debian unstable I get the same > > error as Orion. This is clearly a feature of a stricter new version of > > the linker. Seems a good thing to me. > > > > Hi Andrew: > > Thanks for that confirmation of the distro-related change that I had > hypothesized. As a general rule it is always a mistake to encourage > errors (such as incorrect direct linking) by attempting to work around > the error in advance. So I strongly agree that the very latest Linux > distros (e.g. Debian unstable and Fedora) are doing the right thing > here by deploying a stricter linker. Better late than never! > > I am going to leave it to you to correct x17.cc in case there are > more issues Debian unstable detects with the C++ examples. > > Today, I plan to expand use of NON_TRANSITIVE to languages other than > C++. I will start with C (i.e., libplplotd + all the libraries in > lib). I have fixed up C++ example 17 (and 3 others) where the C API was being used rather than the C++ wrapper class. The C++ examples now all compile fine with -DNON_TRANSITIVE=ON . Andrew |
From: Arjen M. <arj...@de...> - 2011-11-30 14:31:25
|
Hi Orion, On 2011-11-30 15:24, Orion Poplawski wrote: > > Actually, I don't have a big opinion on it, but I do think that the mod > and library should get installed into the examples/f95 directory instead > of the main system locations. > Yes, I agree with that. I have not looked at Alan's changes yet, but he seems to have decided to put them in the main locations. We can always revisit that, once the linkage issue has settled. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2011-11-24 03:27:30
|
On 2011-11-23 17:48-0700 Orion Poplawski wrote: Hi Orion: Thanks for those tests. Let's start with C++ to try and understand what is going on in that case. > > /usr/lib/ccache/c++ x17.cc -o x17 `pkg-config --cflags --libs plplotd-c++` > /usr/bin/ld: /tmp/ccUpkDBH.o: undefined reference to symbol 'c_plrandd' > /usr/bin/ld: note: 'c_plrandd' is defined in DSO /usr/lib/libplplotd.so.11 so > try adding it to the linker command line > /usr/lib/libplplotd.so.11: could not read symbols: Invalid operation > Here is what plplotd-c++.pc looks like on my system with your Requires.private change. libdir=/home/software/plplot_svn/installcmake/lib includedir=/home/software/plplot_svn/installcmake/include/plplot drvdir=/home/software/plplot_svn/installcmake/lib/plplot5.9.9/driversd Name: PLplot C++ Description: Scientific plotting library (C++ bindings, double precision) Requires.private: plplotd Version: 5.9.9 Libs: -L${libdir} -lplplotcxxd Cflags: -I${includedir} So libdir and includedir are fine, and the assumption (for shared libraries that ignore Requires.private) is that all symbols in the C++ examples will be resolved by libplplotcxxd. That assumption should normally be correct, but it is violated by c++/x17.cc which has the following line: noise = plrandd() - 0.5; which refers directly to our C API rather than the correct C++ wrapper function: noise = pls->randd() - 0.5; In other words, we haven't been as careful as we should with the C++ examples to replace the C API with the C++ API, and your test caught that. However, since you didn't get any errors prior to example 17 it appears we are doing exactly the right thing for the C++ case from the pkg-config Requires.private: perspective (and also from the CMake drop transative linking perspective). (Of course, this conclusion is subject to removing this example 17 error and any other similar errorr in the C++ examples after example 17.) Unlike C++, the other languages do not allow arbitrary mixing of C API into their examples so probably whatever is wrong in those cases is due to a variety of issues. Nevertheless, the good results you have found for most C++ examples (and the simple explanation of the C++ error you found for one of the examples) are encouraging and probably mean the basic approach is correct. That means we can probably continue with moving to Requires.private: for pkg-config and dropping transitive linking for CMake languages subject to tracking down the origin of the errors you found for other languages. > So I think it is probably worth it to keep plplotd in the Requires, but > perhaps move the others items out of the plplotd.pc Requires. I suggest not doing that since I would far prefer to have our C++ users encouraged to use just our C++ API by our cmake and traditional Makefile+pkg-config build systems for the installed examples. Here are my further plans: Implement the NON_TRANSITIVE option for our build system that will drop transitive linking for the CMake case and replace Requires: by Requires.private: for the pkg-config case. This option will be experimental and will default to OFF. Then I plan to go through our languages (starting with C++) one by one to deal with all the various issues that are found with turning that option ON. Orion, could you answer the question that occurred by one of the posters in the "transitive linking topics" thread on the CMake list about why rpmlint is complaining about this "formal" overlinking issue? I responded at the time by some speculation that it has to do with eliminating unnecessary package dependencies, but it would be nice if you could follow up (there if still subscribed or here, otherwise) with the definitive answer. Same question to Andrew about the complaints about overlinking from the Debian packaging software. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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: Alan W. I. <ir...@be...> - 2011-11-24 07:26:01
|
On 2011-11-23 19:27-0800 Alan W. Irwin wrote: > Here are my further plans: > > Implement the NON_TRANSITIVE option for our build system that will > drop transitive linking for the CMake case and replace Requires: by > Requires.private: for the pkg-config case. This option will be > experimental and will default to OFF. Then I plan to go through our > languages (starting with C++) one by one to deal with all the various > issues that are found with turning that option ON. > DONE and completely tested for the shared library case on my Debian stable platform for C++ (as of revision 12033). The "ldd -u" results for the C++ examples are extremely abbreviated compared to those for C, e.g., software@raven> ldd -u examples/c/x01c Unused direct dependencies: /home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.11 /lib/libm.so.6 /usr/lib/libltdl.so.7 /lib/libdl.so.2 /home/software/plplot_svn/HEAD/build_dir/lib/csa/libcsirocsa.so.0 /home/software/plplot_svn/HEAD/build_dir/lib/nn/libcsironn.so.0 /home/software/qhull/install/lib/libqhull.so.5 /home/software/plplot_svn/HEAD/build_dir/lib/qsastime/libqsastime.so.0 /usr/lib/libfreetype.so.6 software@raven> ldd -u examples/c++/x01 Unused direct dependencies: /home/software/plplot_svn/HEAD/build_dir/bindings/c++/libplplotcxxd.so.10 /lib/libm.so.6 /lib/libgcc_s.so.1 In fact, the rpmlint tests for unused direct dependencies may not be quite equivalent to "ldd -u" since that command obviously provides erroneous results above, e.g., we know that direct linking of libplplotcxxd and libm is required for the C++ examples and those libraries are definitely used as well contrary to what is reported by "ldd -u". A similar situation may apply for libgcc_s so that you might get a completely clean rpmlint report for the C++ examples. (But currently libplplotcxx will still have warning messages because I haven't yet implemented non-transitive linking for our C libraries). Another issue is my Debian stable system had no problems with the call to c_plrandd (resolved only by libplplotd) in C++ example 17 even though I checked that in all the three cases (build tree and traditional and CMake-based installed examples), the example was linked just with libplplotcxxd and not libplplotd. So the only way I can explain this difference between my results and yours (assuming you confirm problems with example 17 still persist) is the Debian stable run-time loader resolves symbols by promiscuously searching through all the indirectly linked libraries (e.g., libplplotd linked by libplplotcxxd but not the C++ examples) while the Fedora run-time loader only searches through directly linked libraries (i.e., libplplotcxxd for the C++ examples) so it cannot resolve the c_plrandd symbol in x17.cc. Orion, just for now I am going to leave the call to plrandd (a.k.a. c_plrandd) in examples/c++/x17.cc as a test to see whether you continue to get the bad C++ results on Fedora because of that. Here is how I tested the C++ case (and I suggest you do the same) where PL_PREFIX is an environment variable set to your preferred PLplot install prefix which should be initially empty just like the directories I create below with mkdir. mkdir build_dir cd build_dir cmake -DCMAKE_INSTALL_PREFIX=$PL_PREFIX \ -DBUILD_TEST=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON \ -DNON_TRANSITIVE=ON /path/to/top/of/source_tree # Build tree test: make test_diff_psc # Prerequisite for installed examples tests: make install # CMake-based installed examples: mkdir install_build_dir cd install_build_dir cmake $PL_PREFIX/share/plplot5.9.9/examples make test_diff_psc # Traditional installed examples: cd .. mkdir traditional_build_tree cp -a $PL_PREFIX/share/plplot5.9.9/examples traditional_build_tree cd traditional_build_tree/examples make compare If C++ example 17 gives trouble (which I assume it will) please replace the plrandd C call with the correct C++ form and try the above tests again. If that works, I will commit the change as well. Assuming you do prove that Fedora is more unforgiving than Debian stable, then my plan is to get rid of all errors generated by -DNON_TRANSITIVE=ON one language at a time (just like I have just done for C++), and then pass off the further testing of that language to you to see what further changes have to be made for that language to satisfy Fedora. I am game to keep going with this as long as you are! 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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: Alan W. I. <ir...@be...> - 2011-11-25 23:39:01
|
Hi Andrew: Thanks for your additional tests of the -DNON_TRANSITIVE=ON case. On 2011-11-25 09:51-0000 Andrew Ross wrote: > Ada also doesn't work, although the situation is more complicated. I > don't understand enough about ada, but it appears that building the > examples is linking in the .o files from > bindings/ada/CMakeFiles/plplotadad.dir/ and these reference C API > functions. This seems odd to me so I don't know whether it is a "bug" or > a feature. At the moment it looks like libplplotd would need to be > explicitly linked in. I can't see how to do this though. The gnat > manpages are brief to say the least... There is complete documentation of gnat in info form that you may need to install on your Debian unstable system. If it turns out that libplplotd really has to be directly linked by the Ada examples, then I suggest you make the following change in examples/ada/CMakeLists.txt to accomplish that: target_link_libraries(${TARGET_NAME} plplotada${LIB_TAG}) ==> target_link_libraries(${TARGET_NAME} plplotada${LIB_TAG} plplot${LIB_TAG}) I think the above will just work, but if it doesn't because of some limitation of our Ada language support you might also have to work around that problem by changing the adalinkflags variable defined in that file to specify the location of libplplotd in the two cases (core build, and installed examples build). > [....]Incidentally gdc works fine. By default D is compiled statically because the shared D build is broken on Debian stable because of a bug in D support on that platform. Has that bug been fixed for Debian unstable? In other words, do you get good results for the combination of -DNON_TRANSITIVE=ON and -Dplplotdmd_SHARED=ON? The second of those options forces a shared build of our D interface. However, that breaks the build on Debian stable (with or without -DNON_TRANSITIVE=ON) so all I can test here is Dplplotdmd_SHARED=OFF, which forces a static D build. For such static builds -DNON_TRANSITIVE=ON effectively turns into a no-op (since the empty LINK_INTERFACE_LIBRARIES property for targets is ignored for static libraries). 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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: Andrew R. <and...@us...> - 2011-11-27 20:18:39
|
On Fri, Nov 25, 2011 at 03:38:53PM -0800, Alan Irwin wrote: > Hi Andrew: > > Thanks for your additional tests of the -DNON_TRANSITIVE=ON case. > > On 2011-11-25 09:51-0000 Andrew Ross wrote: > > > Ada also doesn't work, although the situation is more complicated. I > > don't understand enough about ada, but it appears that building the > > examples is linking in the .o files from > > bindings/ada/CMakeFiles/plplotadad.dir/ and these reference C API > > functions. This seems odd to me so I don't know whether it is a "bug" or > > a feature. At the moment it looks like libplplotd would need to be > > explicitly linked in. I can't see how to do this though. The gnat > > manpages are brief to say the least... > > There is complete documentation of gnat in info form that you may need > to install on your Debian unstable system. > > If it turns out that libplplotd really has to be directly linked by > the Ada examples, then I suggest you make the following change in > examples/ada/CMakeLists.txt to accomplish that: > > target_link_libraries(${TARGET_NAME} plplotada${LIB_TAG}) > > ==> > > target_link_libraries(${TARGET_NAME} plplotada${LIB_TAG} plplot${LIB_TAG}) > > I think the above will just work, but if it doesn't because of some > limitation of our Ada language support you might also have to work > around that problem by changing the adalinkflags variable defined in > that file to specify the location of libplplotd in the two cases (core > build, and installed examples build). Your suggestion does just work for the build tree examples. I guess the pkg-config support will need fixing as well. I've not yet looked at this. > > > [....]Incidentally gdc works fine. > > By default D is compiled statically because the shared D build is > broken on Debian stable because of a bug in D support on that > platform. Has that bug been fixed for Debian unstable? In other > words, do you get good results for the combination of > -DNON_TRANSITIVE=ON and -Dplplotdmd_SHARED=ON? > > The second of those options forces a shared build of our D interface. > However, that breaks the build on Debian stable (with or without > -DNON_TRANSITIVE=ON) so all I can test here is Dplplotdmd_SHARED=OFF, > which forces a static D build. For such static builds > -DNON_TRANSITIVE=ON effectively turns into a no-op (since the empty > LINK_INTERFACE_LIBRARIES property for targets is ignored for static > libraries). Well, trying with -Dplplotdmd_SHARED=ON fails with the default gdc (gdc-4.4) with an error message about one of the .a files needing recompiling with -fPIC. Is this the error you are talking about? I also tried gdc-4.6 which is also available in unstable. This fails during the cmake D compiler checks. Cmake adds the -fversion=Posix option to the compiler, which does not seem to be allowed by gdc-4.6. Not sure if this is a gdc error (flag should be supported) or a cmake issue. I can't find any documentation on -fversion=Posix to confirm or deny this. Anyone with any D lanugage experience able to offer advice? Andrew |
From: Alan W. I. <ir...@be...> - 2011-11-24 09:16:20
|
On 2011-11-24 07:37-0000 Andrew Ross wrote: >> Orion, could you answer the question that occurred by one of the >> posters in the "transitive linking topics" thread on the CMake list >> about why rpmlint is complaining about this "formal" overlinking >> issue? I responded at the time by some speculation that it has to do >> with eliminating unnecessary package dependencies, but it would be >> nice if you could follow up (there if still subscribed or here, >> otherwise) with the definitive answer. >> >> Same question to Andrew about the complaints about overlinking from >> the Debian packaging software. > > Alan, > > The Debian warning is precisely for that reason. Unnecessary linkages > produce unnecessary package dependencies, which in turn adds complication > and can cause difficulties for smooth upgrades of package versions. Hi Andrew: There was just an answer to this effect on the CMake list with what to my mind is a really good example of the benefits of dropping unnecessary linking. Hendrik Sattler said: "The issue is the packaging in distributions. When application A depends on library B (which depends on library C) but links to both B and C, you have to rebuild A and B when the ABI of C changes. If A only links to B, only B has to be rebuilt and the distribution user has to download far less. So it is an optimisation of many ressources which consumes less energy -> good :-)" > > Plus it is cleaner and clearer to only link in the required libraries. > It catches errors like the C++ one you pointed out. Apparently that error is caught on Fedora but not Debian stable for reasons I don't understand. I wonder if it is also caught on Debian testing, recent Ubuntu, etc., i.e., I wonder if Debian stable is out of step with modern distributions in this regard. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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: Andrew R. <and...@us...> - 2011-11-24 12:19:34
|
On Thu, Nov 24, 2011 at 01:16:06AM -0800, Alan Irwin wrote: > On 2011-11-24 07:37-0000 Andrew Ross wrote: > > >> Orion, could you answer the question that occurred by one of the > >> posters in the "transitive linking topics" thread on the CMake list > >> about why rpmlint is complaining about this "formal" overlinking > >> issue? I responded at the time by some speculation that it has to do > >> with eliminating unnecessary package dependencies, but it would be > >> nice if you could follow up (there if still subscribed or here, > >> otherwise) with the definitive answer. > >> > >> Same question to Andrew about the complaints about overlinking from > >> the Debian packaging software. > > > > Alan, > > > > The Debian warning is precisely for that reason. Unnecessary linkages > > produce unnecessary package dependencies, which in turn adds complication > > and can cause difficulties for smooth upgrades of package versions. > > Hi Andrew: > > There was just an answer to this effect on the CMake list with what to > my mind is a really good example of the benefits of dropping > unnecessary linking. Hendrik Sattler said: > > "The issue is the packaging in distributions. When application A > depends on library B (which depends on library C) but links to both B > and C, you have to rebuild A and B when the ABI of C changes. If A > only links to B, only B has to be rebuilt and the distribution user > has to download far less. So it is an optimisation of many ressources > which consumes less energy -> good :-)" > > > > > Plus it is cleaner and clearer to only link in the required libraries. > > It catches errors like the C++ one you pointed out. > > Apparently that error is caught on Fedora but not Debian stable for > reasons I don't understand. I wonder if it is also caught on > Debian testing, recent Ubuntu, etc., i.e., I wonder if Debian stable > is out of step with modern distributions in this regard. I haven't had chance yet, but I will try your patch to see if it reduces the warnings / generates any errors for the current plplot packages on debian unstable. Andrew |
From: Andrew R. <and...@us...> - 2011-11-30 11:40:51
|
On Wed, Nov 30, 2011 at 11:11:47AM +0000, Andrew Ross wrote: > On Tue, Nov 29, 2011 at 04:54:27PM -0700, Orion Poplawski wrote: > > On 11/28/2011 11:56 PM, Alan W. Irwin wrote: > >> So this should complete my NON_TRANSITIVE changes to the build system. > >> > >> Orion and Andrew: I hope this effort has been worth it and greatly > >> reduces packaging warnings you have been getting on both Fedora and Debian > >> concerning overlinking. > > > > Thanks for the work on this. Here's where it stands from my testing: > > > > Build failures: > > > > /usr/lib/ccache/gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > > -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 > > -march=i686 -mtune=atom -fasynchronous-unwind-tables > > CMakeFiles/plserver.dir/plserver.c.o -o plserver -rdynamic > > ../../src/libplplotd.so.11.0.0 ../tcl/libplplottcltkd.so.9.2.0 > > ../../src/libplplotd.so.11.0.0 > > -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.9/fedora/src:/builddir/build/BUILD/plplot-5.9.9/fedora/bindings/tcl:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/qsastime: > > > > -Wl,-rpath-link,/builddir/build/BUILD/plplot-5.9.9/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/qsastime:/builddir/build/BUILD/plplot-5.9.9/fedora/bindings/tcl > > > > > > /usr/bin/ld: CMakeFiles/plserver.dir/plserver.c.o: undefined reference > > to symbol 'Tcl_SetVar' > > /usr/bin/ld: note: 'Tcl_SetVar' is defined in DSO /usr/lib/libtcl8.5.so > > so try adding it to the linker command line > > /usr/lib/libtcl8.5.so: could not read symbols: Invalid operation > > > > And: > > > > /usr/bin/ld: CMakeFiles/plserver.dir/plserver.c.o: undefined reference > > to symbol 'Tk_ParseArgv' > > /usr/bin/ld: note: 'Tk_ParseArgv' is defined in DSO /usr/lib/libtk8.5.so > > so try adding it to the linker command line > > > > The Fedora linker requires explicit linking to libraries used by the > > compiled code. The attached patch fixes this and similar errors. > > This is always the case I think. Debian also requires this. I confirm your > patch for tcl / tk fixes things for me and I have applied it to svn > > > rpmlint shlib ouput: > > > > plplot-libs.i686: W: unused-direct-shlib-dependency > > /usr/lib/libplplotf77d.so.9.1.1 /lib/libm.so.6 > > plplot-libs.i686: W: unused-direct-shlib-dependency > > /usr/lib/libplplotf77d.so.9.1.1 /lib/libgcc_s.so.1 > > plplot-libs.i686: W: unused-direct-shlib-dependency > > /usr/lib/libplplotf77d.so.9.1.1 /usr/lib/libquadmath.so.0 > > > > plplot-libs.i686: W: unused-direct-shlib-dependency > > /usr/lib/libplplotf95d.so.9.1.1 /lib/libm.so.6 > > plplot-libs.i686: W: unused-direct-shlib-dependency > > /usr/lib/libplplotf95d.so.9.1.1 /lib/libgcc_s.so.1 > > plplot-libs.i686: W: unused-direct-shlib-dependency > > /usr/lib/libplplotf95d.so.9.1.1 /usr/lib/libquadmath.so.0 > > > > These may just be issues with gfortran as these don't appear on the link > > line. > > > > plplot-libs.i686: W: unused-direct-shlib-dependency > > /usr/lib/libplplotcxxd.so.10.0.0 /lib/libm.so.6 > > plplot-libs.i686: W: unused-direct-shlib-dependency > > /usr/lib/libplplotcxxd.so.10.0.0 /lib/libgcc_s.so.1 > > > > same here with g++ > > > > plplot-libs.i686: W: unused-direct-shlib-dependency > > /usr/lib/libplplotd.so.11.0.0 /lib/libdl.so.2 > > > > plplot-qt.i686: W: unused-direct-shlib-dependency > > /usr/lib/libplplotqtd.so.0.0.1 /usr/lib/libQtXml.so.4 > > > > plplot-tk.i686: W: unused-direct-shlib-dependency > > /usr/lib/libplplottcltkd.so.9.2.0 /usr/lib/libSM.so.6 > > plplot-tk.i686: W: unused-direct-shlib-dependency > > /usr/lib/libplplottcltkd.so.9.2.0 /usr/lib/libICE.so.6 > > plplot-tk.i686: W: unused-direct-shlib-dependency > > /usr/lib/libplplottcltkd.so.9.2.0 /usr/lib/libXext.so.6 > > > > plplot-wxGTK.i686: W: unused-direct-shlib-dependency > > /usr/lib/libplplotwxwidgetsd.so.0.0.0 /usr/lib/libagg.so.2 > > plplot-wxGTK.i686: W: unused-direct-shlib-dependency > > /usr/lib/libplplotwxwidgetsd.so.0.0.0 /usr/lib/libaggfontfreetype.so.2 > > plplot-wxGTK.i686: W: unused-direct-shlib-dependency > > /usr/lib/libplplotwxwidgetsd.so.0.0.0 /usr/lib/libfreetype.so.6 > > plplot-wxGTK.i686: W: unused-direct-shlib-dependency > > /usr/lib/libplplotwxwidgetsd.so.0.0.0 /lib/libm.so.6 > > plplot-wxGTK.i686: W: unused-direct-shlib-dependency > > /usr/lib/libplplotwxwidgetsd.so.0.0.0 /lib/libpthread.so.0 > > > > Some other rpmlint issues: > > > > > > plplot.i686: W: file-not-utf8 /usr/share/doc/plplot-5.9.9/README.release > > plplot.i686: E: incorrect-fsf-address > > /usr/share/doc/plplot-5.9.9/COPYING.LIB > > plplot-octave.i686: E: incorrect-fsf-address > > /usr/share/plplot_octave/struct_contains.m > > I agree with you Orion that this should probably be fixed. I recently > fixed up Copyright for the same reason (wrong address) as Debian lintian > complained about it. Debian doesn't install COPYING.LIB. I maintains > central copies of the GPL licenses and links to these so I didn't fix > COPYING.LIB as well. > > > Building examples in the installed tree with make: > > > > /usr/bin/gnatmake -aI/usr/share/ada/adainclude/plplotadad > > -aL/usr/lib/ada/adalib/plplotadad x15a.adb \ > > -cargs `PKG_CONFIG_PATH=/usr/lib/pkgconfig pkg-config --cflags > > plplotd-ada` -largs `PKG_CONFIG_PATH=/usr/lib/pkgconfig pkg-config > > --libs plplotd-ada` > > gcc -c -I/usr/share/ada/adainclude/plplotadad -I/usr/include/plplot x15a.adb > > gnatbind -aI/usr/share/ada/adainclude/plplotadad > > -aO/usr/lib/ada/adalib/plplotadad -x x15a.ali > > gnatlink x15a.ali -lplplotadad > > /usr/bin/ld: ./x15a.o: undefined reference to symbol 'c_plfill' > > /usr/bin/ld: note: 'c_plfill' is defined in DSO > > /usr/lib/libplplotd.so.11 so try adding it to the linker command line > > I think this is because the plfill is being passed as a function argument > in this case. I don't understand enough about ada to know why this is a > problem but I suspect we need to explicitly link to plplotd in the > pkgconfig-ada file. We do this for the cmake build of the examples > already. > > > /usr/lib/ccache/c++ wxPLplotDemo.cpp -o wxPLplotDemo `pkg-config > > --cflags --libs plplotd-wxwidgets` > > /usr/bin/ld: /tmp/cc2nmLCB.o: undefined reference to symbol > > 'plstream::line(int, double const*, double const*)' > > /usr/bin/ld: note: 'plstream::line(int, double const*, double const*)' > > is defined in DSO /usr/lib/libplplotcxxd.so.10 so try adding it to the > > linker command line > > This is a less obvious error since the source code does not directly > mention plstream, but the wxPlplotstream class inherits from plstream > and so plplotcxxd needs explicitly linking in for pkgconfig-wxwidgets > > > cd f95; make > > make[1]: Entering directory `/usr/share/plplot5.9.9/examples/f95' > > /usr/bin/gfortran x01f.f90 -o x01f `pkg-config --cflags --libs > > plplotd-f95` > > x01f.f90:24.19: > > > > use plf95demolib > > 1 > > Fatal Error: Can't open module file 'plf95demolib.mod' for reading at > > (1): No such file or directory > > > > This file does not appear to have been installed. > > This is odd - I do not see this error. The .mod file is installed in > lib/fortran/modules/plplot for me. > > > make[1]: Entering directory `/usr/share/plplot5.9.9/examples/tk' > > /usr/lib/ccache/gcc xtk01.c -o xtk01 `pkg-config --cflags --libs > > plplotd-tcl` > > /usr/bin/ld: /tmp/ccJlYbFQ.o: undefined reference to symbol 'c_plvsta' > > /usr/bin/ld: note: 'c_plvsta' is defined in DSO > > /usr/lib/libplplotd.so.11 so try adding it to the linker command line > > Confirmed. > > In addition the d language examples fail to explcitly link in plplotd > for the install tree examples. > > I'll try and fix these up. Incidentally, examples works fine in the > install tree if you use the cmake build system (1 issue with tk examples > now fixed) and they also work fine in the build tree. > > Andrew I have fixed all the issues I have found. Still outstanding is Orions fortran issue (I don't see this) and the copyright issue. Andrew |
From: Andrew R. <and...@us...> - 2011-11-30 14:30:20
|
On Wed, Nov 30, 2011 at 11:40:42AM +0000, Andrew Ross wrote: > > I have fixed all the issues I have found. Still outstanding is Orions > fortran issue (I don't see this) and the copyright issue. Building the full debian packages using svn and -DNON_TRANSITIVE=ON produces the following linkage related warnings. I think I have fixed the libscironn linking against -lm and wxwidgets linking against libplplotd issues. The remaining ones seem mostly to do with extra external libraries pulled in for X / cairo / gd etc from the pkg-config / cmake generated library lists. There are also a number that seem related to libraries the compiler automatically includes. There is also the libdl issue Orion mentioned. We've cleaned this up a lot, but it is still not perfect. Andrew dh_shlibdeps -a --no-package=octave-plplot -L libplplot11 \ -l /tmp/buildd/plplot-5.9.9/debian/libplplot11/usr/lib:/tmp/buildd/plplot-5.9.9/debian/plplot-tcl/usr/lib dpkg-shlibdeps: warning: dependency on libdl.so.2 could be avoided if "debian/libplplot11/usr/lib/libplplotd.so.11.0.0" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libgcc_s.so.1 could be avoided if "debian/libplplot-c++10/usr/lib/libplplotcxxd.so.10.0.0" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libgcc_s.so.1 could be avoided if "debian/libplplot-fortran9/usr/lib/libplplotf77d.so.9.1.1 debian/libplplot-fortran9/usr/lib/libplplotf95d.so.9.1.1" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libquadmath.so.0 could be avoided if "debian/libplplot-fortran9/usr/lib/libplplotf77d.so.9.1.1 debian/libplplot-fortran9/usr/lib/libplplotf95d.so.9.1.1" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libm.so.6 could be avoided if "debian/libplplot-fortran9/usr/lib/libplplotf77d.so.9.1.1 debian/libplplot-fortran9/usr/lib/libplplotf95d.so.9.1.1" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: symbol hypot used by debian/libcsiro0/usr/lib/libcsironn.so.0.0.1 found in none of the libraries. dpkg-shlibdeps: warning: dependency on libSM.so.6 could be avoided if "debian/plplot11-driver-xwin/usr/lib/plplot5.9.9/driversd/xwin.so" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libICE.so.6 could be avoided if "debian/plplot11-driver-xwin/usr/lib/plplot5.9.9/driversd/xwin.so" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libXext.so.6 could be avoided if "debian/plplot11-driver-xwin/usr/lib/plplot5.9.9/driversd/xwin.so" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: symbol c_plreplot used by debian/plplot11-driver-wxwidgets/usr/lib/libplplotwxwidgetsd.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol c_plend1 used by debian/plplot11-driver-wxwidgets/usr/lib/libplplotwxwidgetsd.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol c_plcpstrm used by debian/plplot11-driver-wxwidgets/usr/lib/libplplotwxwidgetsd.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol plsfile used by debian/plplot11-driver-wxwidgets/usr/lib/libplplotwxwidgetsd.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol c_plspage used by debian/plplot11-driver-wxwidgets/usr/lib/libplplotwxwidgetsd.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol c_plsstrm used by debian/plplot11-driver-wxwidgets/usr/lib/libplplotwxwidgetsd.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol c_plgstrm used by debian/plplot11-driver-wxwidgets/usr/lib/libplplotwxwidgetsd.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol c_plsdev used by debian/plplot11-driver-wxwidgets/usr/lib/libplplotwxwidgetsd.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol c_pladv used by debian/plplot11-driver-wxwidgets/usr/lib/libplplotwxwidgetsd.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol c_plmkstrm used by debian/plplot11-driver-wxwidgets/usr/lib/libplplotwxwidgetsd.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: dependency on libfreetype.so.6 could be avoided if "debian/plplot11-driver-wxwidgets/usr/lib/libplplotwxwidgetsd.so.0.0.0 debian/plplot11-driver-wxwidgets/usr/lib/plplot5.9.9/driversd/wxwidgets.so" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if "debian/plplot11-driver-wxwidgets/usr/lib/libplplotwxwidgetsd.so.0.0.0 debian/plplot11-driver-wxwidgets/usr/lib/plplot5.9.9/driversd/wxwidgets.so" were not uselessly linked against it (they use none of its symbols). pkg-shlibdeps: warning: dependency on libSM.so.6 could be avoided if "debian/plplot-tcl/usr/lib/plplot5.9.9/driversd/tk.so debian/plplot-tcl/usr/lib/libplplottcltkd.so. 9.2.0 debian/plplot-tcl/usr/bin/plserver debian/plplot-tcl/usr/lib/plplot5.9.9/driversd/tkwin.so" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libm.so.6 could be avoided if "debian/plplot-tcl/usr/lib/plplot5.9.9/driversd/tk.so debian/plplot-tcl/usr/lib/plplot5.9.9/driversd /tkwin.so" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libICE.so.6 could be avoided if "debian/plplot-tcl/usr/lib/plplot5.9.9/driversd/tk.so debian/plplot-tcl/usr/lib/libplplottcltkd.so .9.2.0 debian/plplot-tcl/usr/bin/plserver debian/plplot-tcl/usr/lib/plplot5.9.9/driversd/tkwin.so" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libXext.so.6 could be avoided if "debian/plplot-tcl/usr/lib/plplot5.9.9/driversd/tk.so debian/plplot-tcl/usr/lib/libplplottcltkd.s o.9.2.0 debian/plplot-tcl/usr/bin/plserver debian/plplot-tcl/usr/lib/plplot5.9.9/driversd/tkwin.so" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libz.so.1 could be avoided if "debian/plplot11-driver-gd/usr/lib/plplot5.9.9/driversd/gd.so" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libm.so.6 could be avoided if "debian/plplot11-driver-gd/usr/lib/plplot5.9.9/driversd/gd.so" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libfreetype.so.6 could be avoided if "debian/plplot11-driver-gd/usr/lib/plplot5.9.9/driversd/gd.so" were not uselessly linked agai nst it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libjpeg.so.8 could be avoided if "debian/plplot11-driver-gd/usr/lib/plplot5.9.9/driversd/gd.so" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libpng12.so.0 could be avoided if "debian/plplot11-driver-gd/usr/lib/plplot5.9.9/driversd/gd.so" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libgmodule-2.0.so.0 could be avoided if "debian/plplot11-driver-cairo/usr/lib/plplot5.9.9/driversd/cairo.so" were not uselessly li nked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libSM.so.6 could be avoided if "debian/plplot11-driver-cairo/usr/lib/plplot5.9.9/driversd/cairo.so" were not uselessly linked agai nst it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libglib-2.0.so.0 could be avoided if "debian/plplot11-driver-cairo/usr/lib/plplot5.9.9/driversd/cairo.so" were not uselessly linke d against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libgthread-2.0.so.0 could be avoided if "debian/plplot11-driver-cairo/usr/lib/plplot5.9.9/driversd/cairo.so" were not uselessly li nked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libICE.so.6 could be avoided if "debian/plplot11-driver-cairo/usr/lib/plplot5.9.9/driversd/cairo.so" were not uselessly linked aga inst it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libXext.so.6 could be avoided if "debian/plplot11-driver-cairo/usr/lib/plplot5.9.9/driversd/cairo.so" were not uselessly linked ag ainst it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on librt.so.1 could be avoided if "debian/plplot11-driver-cairo/usr/lib/plplot5.9.9/driversd/cairo.so" were not uselessly linked agai nst it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if "debian/plplot11-driver-cairo/usr/lib/plplot5.9.9/driversd/cairo.so" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: debian/python-plplot/usr/lib/python2.6/dist-packages/_plplotcmodule.so contains an unresolvable reference to symbol PyCapsule_GetPointer: it's probably a plugin. dpkg-shlibdeps: warning: 2 other similar warnings have been skipped (use -v to see them all). dpkg-shlibdeps: warning: debian/python-plplot-qt/usr/lib/python2.6/dist-packages/plplot_pyqt4.so contains an unresolvable reference to symbol PyCapsule_GetPointer: it's probably a plugin. dpkg-shlibdeps: warning: 1 similar warning has been skipped (use -v to see it). dpkg-shlibdeps: warning: dependency on libQtSvg.so.4 could be avoided if "debian/python-plplot-qt/usr/lib/python2.6/dist-packages/plplot_pyqt4.so debian/python-plplot-qt/usr/lib/python2.7/dist-packages/plplot_pyqt4.so" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libplplotd.so.11 could be avoided if "debian/python-plplot-qt/usr/lib/python2.6/dist-packages/plplot_pyqt4.so debian/python-plplot-qt/usr/lib/python2.7/dist-packages/plplot_pyqt4.so" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libQtXml.so.4 could be avoided if "debian/python-plplot-qt/usr/lib/python2.6/dist-packages/plplot_pyqt4.so debian/python-plplot-qt/usr/lib/python2.7/dist-packages/plplot_pyqt4.so" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: debian/plplot11-driver-qt/usr/lib/plplot5.9.9/driversd/qt.so contains an unresolvable reference to symbol _ZN6QMutex4lockEv: it's probably a plugin. dpkg-shlibdeps: warning: 19 other similar warnings have been skipped (use -v to see them all). dpkg-shlibdeps: warning: dependency on libQtXml.so.4 could be avoided if "debian/plplot11-driver-qt/usr/lib/libplplotqtd.so.0.0.1" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libcairo.so.2 could be avoided if "debian/libplplot-ocaml/usr/lib/ocaml/stublibs/dllplcairo_stubs.so" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libm.so.6 could be avoided if "debian/libplplot-lua/usr/lib/lua/5.1/plplot/plplotluac.so" were not uselessly linked against it (they use none of its symbols). |
From: Orion P. <or...@co...> - 2011-11-30 17:49:23
Attachments:
plplot-libs.patch
|
On 11/30/2011 07:30 AM, Andrew Ross wrote: > On Wed, Nov 30, 2011 at 11:40:42AM +0000, Andrew Ross wrote: >> >> I have fixed all the issues I have found. Still outstanding is Orions >> fortran issue (I don't see this) and the copyright issue. Here's what I have with svn12076: make[1]: Entering directory `/usr/share/plplot5.9.9/examples/tk' /usr/lib/ccache/gcc xtk01.c -o xtk01 `pkg-config --cflags --libs plplotd-tcl` /usr/bin/ld: /tmp/ccZTLMLN.o: undefined reference to symbol 'cos@@GLIBC_2.0' /usr/bin/ld: note: 'cos@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try adding it to the linker command line -lm needs to be added to the tk/Makefile. See updated patch. I've also made a change to drop dl from libplplotd for NON_TRANSITIVE=ON. Also seeing this: plplot-ocaml.i686: E: binary-or-shlib-defines-rpath /usr/lib/ocaml/stublibs/dllplplot_stubs.so ['/usr/lib/ocaml', '/builddir/build/BUILD/plplot-5.9.9/fedora/src'] plplot-ocaml.i686: E: binary-or-shlib-defines-rpath /usr/lib/ocaml/stublibs/dllplcairo_stubs.so ['/usr/lib', '/builddir/build/BUILD/plplot-5.9.9/fedora/src'] Anyone know why the rpaths aren't being removed on install? Still have: plplot-qt.i686: W: unused-direct-shlib-dependency /usr/lib/libplplotqtd.so.0.0.1 /usr/lib/libQtXml.so.4 from cmake Qt. plplot-wxGTK.i686: W: unused-direct-shlib-dependency /usr/lib/libplplotwxwidgetsd.so.0.0.0 /usr/lib/libfreetype.so.6 plplot-wxGTK.i686: W: unused-direct-shlib-dependency /usr/lib/libplplotwxwidgetsd.so.0.0.0 /lib/libm.so.6 plplot-wxGTK.i686: W: unused-direct-shlib-dependency /usr/lib/libplplotwxwidgetsd.so.0.0.0 /lib/libpthread.so.0 I've dropped FREETYPE_LIBRARIES from wxwidgets_LINK_FLAGS. Perhaps these and the other changes need to wrapped in if(!NON_TRANSTIVE) as well. pthread appears to be coming somehow from the cmake wxWidgets stuff. libm I think is coming again from g++. Trying to build with the attached patch though I get this: /usr/lib/ccache/gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables CMakeFiles/plserver.dir/plserver.c.o -o plserver -rdynamic ../../src/libplplotd.so.11.0.0 ../tcl/libplplottcltkd.so.9.2.0 -ltk -ltcl ../../src/libplplotd.so.11.0.0 -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.9/fedora/src:/builddir/build/BUILD/plplot-5.9.9/fedora/bindings/tcl:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/qsastime: -Wl,-rpath-link,/builddir/build/BUILD/plplot-5.9.9/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/qsastime:/builddir/build/BUILD/plplot-5.9.9/fedora/bindings/tcl ../../src/libplplotd.so.11.0.0: undefined reference to `agg::font_engine_freetype_base::hinting(bool)' .... ../../src/libplplotd.so.11.0.0: undefined reference to `plD_dispatch_init_tek4107f' From the build line for libplplotd.so.11.0.0: /usr/lib/ccache/c++ -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -shared -Wl,-soname,libplplotd.so.11 -o libplplotd.so.11.0.0 CMakeFiles/plplotd.dir/pdfutils.c.o CMakeFiles/plplotd.dir/plaffine.c.o CMakeFiles/plplotd.dir/plarc.c.o CMakeFiles/plplotd.dir/plargs.c.o CMakeFiles/plplotd.dir/plbox.c.o CMakeFiles/plplotd.dir/plcont.c.o CMakeFiles/plplotd.dir/plcore.c.o CMakeFiles/plplotd.dir/plctrl.c.o CMakeFiles/plplotd.dir/plcvt.c.o CMakeFiles/plplotd.dir/pldtik.c.o CMakeFiles/plplotd.dir/plf2ops.c.o CMakeFiles/plplotd.dir/plfill.c.o CMakeFiles/plplotd.dir/plfreetype.c.o CMakeFiles/plplotd.dir/plgradient.c.o CMakeFiles/plplotd.dir/plhist.c.o CMakeFiles/plplotd.dir/plimage.c.o CMakeFiles/plplotd.dir/plline.c.o CMakeFiles/plplotd.dir/plmap.c.o CMakeFiles/plplotd.dir/plot3d.c.o CMakeFiles/plplotd.dir/plpage.c.o CMakeFiles/plplotd.dir/plsdef.c.o CMakeFiles/plplotd.dir/plshade.c.o CMakeFiles/plplotd.dir/plstdio.c.o CMakeFiles/plplotd.dir/plstripc.c.o CMakeFiles/plplotd.dir/plsym.c.o CMakeFiles/plplotd.dir/pltick.c.o CMakeFiles/plplotd.dir/plvpor.c.o CMakeFiles/plplotd.dir/plwind.c.o CMakeFiles/plplotd.dir/plbuf.c.o CMakeFiles/plplotd.dir/plgridd.c.o CMakeFiles/plplotd.dir/plvect.c.o CMakeFiles/plplotd.dir/mt19937ar.c.o CMakeFiles/plplotd.dir/pltime.c.o CMakeFiles/plplotd.dir/pllegend.c.o CMakeFiles/plplotd.dir/__/drivers/cairo.c.o CMakeFiles/plplotd.dir/__/drivers/qt.cpp.o CMakeFiles/plplotd.dir/__/bindings/qt_gui/plqt.cpp.o CMakeFiles/plplotd.dir/__/drivers/mem.c.o CMakeFiles/plplotd.dir/__/drivers/ntk.c.o CMakeFiles/plplotd.dir/__/drivers/null.c.o CMakeFiles/plplotd.dir/__/drivers/ps.c.o CMakeFiles/plplotd.dir/__/drivers/pstex.c.o CMakeFiles/plplotd.dir/__/drivers/psttf.cc.o CMakeFiles/plplotd.dir/__/drivers/svg.c.o CMakeFiles/plplotd.dir/__/drivers/tk.c.o CMakeFiles/plplotd.dir/__/bindings/tcl/tclAPI.c.o CMakeFiles/plplotd.dir/__/bindings/tcl/tclMain.c.o CMakeFiles/plplotd.dir/__/bindings/tk/Pltk_Init.c.o CMakeFiles/plplotd.dir/__/bindings/tk/plframe.c.o CMakeFiles/plplotd.dir/__/bindings/tk/plr.c.o CMakeFiles/plplotd.dir/__/bindings/tk/tcpip.c.o CMakeFiles/plplotd.dir/__/bindings/tk/tkMain.c.o CMakeFiles/plplotd.dir/__/bindings/tcl/tclMatrix.c.o CMakeFiles/plplotd.dir/__/bindings/tcl/matrixInit.c.o CMakeFiles/plplotd.dir/__/drivers/tkwin.c.o CMakeFiles/plplotd.dir/__/bindings/tk-x-plat/Plplotter_Init.c.o CMakeFiles/plplotd.dir/__/bindings/tk-x-plat/plplotter.c.o CMakeFiles/plplotd.dir/__/drivers/wxwidgets_agg.cpp.o CMakeFiles/plplotd.dir/__/drivers/wxwidgets.cpp.o CMakeFiles/plplotd.dir/__/drivers/wxwidgets_app.cpp.o CMakeFiles/plplotd.dir/__/drivers/wxwidgets_dc.cpp.o CMakeFiles/plplotd.dir/__/drivers/wxwidgets_gc.cpp.o CMakeFiles/plplotd.dir/__/drivers/xfig.c.o CMakeFiles/plplotd.dir/__/drivers/xwin.c.o -pthread -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lSM -lICE -lX11 -lXext -lSM -lICE -lX11 -lXext -lpthread -ltcl -ltk -litcl3.4 -litk3.4 -ltcl -ltk -ltcl -ltk -pthread -lLASi -lpangoft2-1.0 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -pthread -lwx_baseu-2.8 -lwx_gtk2u_core-2.8 -lQtSvg -lQtGui -lQtXml -lQtCore -lm ../lib/csa/libcsirocsa.so.0.0.1 ../lib/nn/libcsironn.so.0.0.1 ../lib/qsastime/libqsastime.so.0.0.1 -lfreetype -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lSM -lICE -lX11 -lXext -lpthread -ltcl -ltk -litcl3.4 -litk3.4 -lLASi -lpangoft2-1.0 -lfontconfig -lwx_baseu-2.8 -lwx_gtk2u_core-2.8 -lQtSvg -lQtGui -lQtXml -lQtCore -lm -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.9/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/qsastime: Now, why is 'CMakeFiles/plplotd.dir/__/drivers/wxwidgets_agg.cpp.oCMakeFiles/plplotd.dir/__/drivers/wxwidgets.cpp.o CMakeFiles/plplotd.dir/__/drivers/wxwidgets_app.cpp.o CMakeFiles/plplotd.dir/__/drivers/wxwidgets_dc.cpp.o CMakeFiles/plplotd.dir/__/drivers/wxwidgets_gc.cpp.o' getting put into libplplotd and not libplplotcxxd? So the other languages can output to wx* devices? It's not really a driver though, correct? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Alan W. I. <ir...@be...> - 2011-11-30 19:38:17
|
On 2011-11-30 11:11-0000 Andrew Ross wrote: > On Tue, Nov 29, 2011 at 04:54:27PM -0700, Orion Poplawski wrote: >> plplot.i686: W: file-not-utf8 /usr/share/doc/plplot-5.9.9/README.release >> plplot.i686: E: incorrect-fsf-address >> /usr/share/doc/plplot-5.9.9/COPYING.LIB >> plplot-octave.i686: E: incorrect-fsf-address >> /usr/share/plplot_octave/struct_contains.m > > I agree with you Orion that this should probably be fixed. I recently > fixed up Copyright for the same reason (wrong address) as Debian lintian > complained about it. Debian doesn't install COPYING.LIB. I maintains > central copies of the GPL licenses and links to these so I didn't fix > COPYING.LIB as well. In my rush, I misread some license dates at FSF and got confused by that into thinking we might have an even later LGPL version 2 license than published by FSF. But in fact our 2.0 license is much earlier (June 1991 not June 1999), than theirs (February 1999, see http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html). Furthermore, I have never heard anybody quibble about 2.0 versus 2.1 licensing text so, Andrew, please go ahead and change to LGPL 2.1 so long as you make sure to get the definitive version from FSF. Note there are some other licensing consistency issues you should address. For example, the licensing summary that appears in our source code (e.g., src/plcore.c) refers to LGPL version 2, but the definitive version of that licensing summary( http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html#SEC4) refers to version 2.1. There are possibly other inconsistencies as well between the src/plcore.c licensing summary and the definitive version, and certainly inconsisentencies between the LGPL licensing summary for src/plcore.c and our other source files. So I think what is needed here is a wholesale approach to replace our existing LGPL summaries everywhere in our source code files with the definitive 2.1 version from the above URL. That change would be a pain to do by hand, but I trust you should be able to automate the work by using a find command and appropriate xargs and grep -l to find all files in our source tree that include some version of the LGPL summary. Then for each of those files run a perl script to recognize the lines in the text that contain an existing variation of our licensing summary (by the first few words and last few words of that text to beat line-wrapping and other variations) and replace that text by the definitive version that has the correct comment tag ("//" for C code, "#" for Python code, etc.) 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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: Orion P. <or...@co...> - 2012-01-04 16:12:48
|
On 11/30/2011 10:49 AM, Orion Poplawski wrote: > On 11/30/2011 07:30 AM, Andrew Ross wrote: >> On Wed, Nov 30, 2011 at 11:40:42AM +0000, Andrew Ross wrote: >>> >>> I have fixed all the issues I have found. Still outstanding is Orions >>> fortran issue (I don't see this) and the copyright issue. > > Here's what I have with svn12076: > > > make[1]: Entering directory `/usr/share/plplot5.9.9/examples/tk' > /usr/lib/ccache/gcc xtk01.c -o xtk01 `pkg-config --cflags --libs plplotd-tcl` > /usr/bin/ld: /tmp/ccZTLMLN.o: undefined reference to symbol 'cos@@GLIBC_2.0' > /usr/bin/ld: note: 'cos@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try > adding it to the linker command line > > -lm needs to be added to the tk/Makefile. See updated patch. > > I've also made a change to drop dl from libplplotd for NON_TRANSITIVE=ON. > > Also seeing this: > > plplot-ocaml.i686: E: binary-or-shlib-defines-rpath > /usr/lib/ocaml/stublibs/dllplplot_stubs.so ['/usr/lib/ocaml', > '/builddir/build/BUILD/plplot-5.9.9/fedora/src'] > plplot-ocaml.i686: E: binary-or-shlib-defines-rpath > /usr/lib/ocaml/stublibs/dllplcairo_stubs.so ['/usr/lib', > '/builddir/build/BUILD/plplot-5.9.9/fedora/src'] > > Anyone know why the rpaths aren't being removed on install? > > Still have: > > plplot-qt.i686: W: unused-direct-shlib-dependency > /usr/lib/libplplotqtd.so.0.0.1 /usr/lib/libQtXml.so.4 > > from cmake Qt. > > plplot-wxGTK.i686: W: unused-direct-shlib-dependency > /usr/lib/libplplotwxwidgetsd.so.0.0.0 /usr/lib/libfreetype.so.6 > plplot-wxGTK.i686: W: unused-direct-shlib-dependency > /usr/lib/libplplotwxwidgetsd.so.0.0.0 /lib/libm.so.6 > plplot-wxGTK.i686: W: unused-direct-shlib-dependency > /usr/lib/libplplotwxwidgetsd.so.0.0.0 /lib/libpthread.so.0 > > I've dropped FREETYPE_LIBRARIES from wxwidgets_LINK_FLAGS. Perhaps these and > the other changes need to wrapped in if(!NON_TRANSTIVE) as well. > > pthread appears to be coming somehow from the cmake wxWidgets stuff. > libm I think is coming again from g++. > > > Trying to build with the attached patch though I get this: > > /usr/lib/ccache/gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom > -fasynchronous-unwind-tables CMakeFiles/plserver.dir/plserver.c.o -o plserver > -rdynamic ../../src/libplplotd.so.11.0.0 ../tcl/libplplottcltkd.so.9.2.0 -ltk > -ltcl ../../src/libplplotd.so.11.0.0 > -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.9/fedora/src:/builddir/build/BUILD/plplot-5.9.9/fedora/bindings/tcl:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/qsastime: > -Wl,-rpath-link,/builddir/build/BUILD/plplot-5.9.9/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/qsastime:/builddir/build/BUILD/plplot-5.9.9/fedora/bindings/tcl > > ../../src/libplplotd.so.11.0.0: undefined reference to > `agg::font_engine_freetype_base::hinting(bool)' > .... > ../../src/libplplotd.so.11.0.0: undefined reference to > `plD_dispatch_init_tek4107f' > > From the build line for libplplotd.so.11.0.0: > > /usr/lib/ccache/c++ -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 > -mtune=atom -fasynchronous-unwind-tables -shared -Wl,-soname,libplplotd.so.11 > -o libplplotd.so.11.0.0 CMakeFiles/plplotd.dir/pdfutils.c.o > CMakeFiles/plplotd.dir/plaffine.c.o CMakeFiles/plplotd.dir/plarc.c.o > CMakeFiles/plplotd.dir/plargs.c.o CMakeFiles/plplotd.dir/plbox.c.o > CMakeFiles/plplotd.dir/plcont.c.o CMakeFiles/plplotd.dir/plcore.c.o > CMakeFiles/plplotd.dir/plctrl.c.o CMakeFiles/plplotd.dir/plcvt.c.o > CMakeFiles/plplotd.dir/pldtik.c.o CMakeFiles/plplotd.dir/plf2ops.c.o > CMakeFiles/plplotd.dir/plfill.c.o CMakeFiles/plplotd.dir/plfreetype.c.o > CMakeFiles/plplotd.dir/plgradient.c.o CMakeFiles/plplotd.dir/plhist.c.o > CMakeFiles/plplotd.dir/plimage.c.o CMakeFiles/plplotd.dir/plline.c.o > CMakeFiles/plplotd.dir/plmap.c.o CMakeFiles/plplotd.dir/plot3d.c.o > CMakeFiles/plplotd.dir/plpage.c.o CMakeFiles/plplotd.dir/plsdef.c.o > CMakeFiles/plplotd.dir/plshade.c.o CMakeFiles/plplotd.dir/plstdio.c.o > CMakeFiles/plplotd.dir/plstripc.c.o CMakeFiles/plplotd.dir/plsym.c.o > CMakeFiles/plplotd.dir/pltick.c.o CMakeFiles/plplotd.dir/plvpor.c.o > CMakeFiles/plplotd.dir/plwind.c.o CMakeFiles/plplotd.dir/plbuf.c.o > CMakeFiles/plplotd.dir/plgridd.c.o CMakeFiles/plplotd.dir/plvect.c.o > CMakeFiles/plplotd.dir/mt19937ar.c.o CMakeFiles/plplotd.dir/pltime.c.o > CMakeFiles/plplotd.dir/pllegend.c.o > CMakeFiles/plplotd.dir/__/drivers/cairo.c.o > CMakeFiles/plplotd.dir/__/drivers/qt.cpp.o > CMakeFiles/plplotd.dir/__/bindings/qt_gui/plqt.cpp.o > CMakeFiles/plplotd.dir/__/drivers/mem.c.o > CMakeFiles/plplotd.dir/__/drivers/ntk.c.o > CMakeFiles/plplotd.dir/__/drivers/null.c.o > CMakeFiles/plplotd.dir/__/drivers/ps.c.o > CMakeFiles/plplotd.dir/__/drivers/pstex.c.o > CMakeFiles/plplotd.dir/__/drivers/psttf.cc.o > CMakeFiles/plplotd.dir/__/drivers/svg.c.o > CMakeFiles/plplotd.dir/__/drivers/tk.c.o > CMakeFiles/plplotd.dir/__/bindings/tcl/tclAPI.c.o > CMakeFiles/plplotd.dir/__/bindings/tcl/tclMain.c.o > CMakeFiles/plplotd.dir/__/bindings/tk/Pltk_Init.c.o > CMakeFiles/plplotd.dir/__/bindings/tk/plframe.c.o > CMakeFiles/plplotd.dir/__/bindings/tk/plr.c.o > CMakeFiles/plplotd.dir/__/bindings/tk/tcpip.c.o > CMakeFiles/plplotd.dir/__/bindings/tk/tkMain.c.o > CMakeFiles/plplotd.dir/__/bindings/tcl/tclMatrix.c.o > CMakeFiles/plplotd.dir/__/bindings/tcl/matrixInit.c.o > CMakeFiles/plplotd.dir/__/drivers/tkwin.c.o > CMakeFiles/plplotd.dir/__/bindings/tk-x-plat/Plplotter_Init.c.o > CMakeFiles/plplotd.dir/__/bindings/tk-x-plat/plplotter.c.o > CMakeFiles/plplotd.dir/__/drivers/wxwidgets_agg.cpp.o > CMakeFiles/plplotd.dir/__/drivers/wxwidgets.cpp.o > CMakeFiles/plplotd.dir/__/drivers/wxwidgets_app.cpp.o > CMakeFiles/plplotd.dir/__/drivers/wxwidgets_dc.cpp.o > CMakeFiles/plplotd.dir/__/drivers/wxwidgets_gc.cpp.o > CMakeFiles/plplotd.dir/__/drivers/xfig.c.o > CMakeFiles/plplotd.dir/__/drivers/xwin.c.o -pthread -lpangocairo-1.0 > -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 > -lSM -lICE -lX11 -lXext -lSM -lICE -lX11 -lXext -lpthread -ltcl -ltk -litcl3.4 > -litk3.4 -ltcl -ltk -ltcl -ltk -pthread -lLASi -lpangoft2-1.0 -lpango-1.0 > -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt > -lglib-2.0 -pthread -lwx_baseu-2.8 -lwx_gtk2u_core-2.8 -lQtSvg -lQtGui -lQtXml > -lQtCore -lm ../lib/csa/libcsirocsa.so.0.0.1 ../lib/nn/libcsironn.so.0.0.1 > ../lib/qsastime/libqsastime.so.0.0.1 -lfreetype -lpango-1.0 -lcairo > -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lSM -lICE -lX11 > -lXext -lpthread -ltcl -ltk -litcl3.4 -litk3.4 -lLASi -lpangoft2-1.0 > -lfontconfig -lwx_baseu-2.8 -lwx_gtk2u_core-2.8 -lQtSvg -lQtGui -lQtXml > -lQtCore -lm > -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.9/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/qsastime: > > > Now, why is > 'CMakeFiles/plplotd.dir/__/drivers/wxwidgets_agg.cpp.oCMakeFiles/plplotd.dir/__/drivers/wxwidgets.cpp.o > CMakeFiles/plplotd.dir/__/drivers/wxwidgets_app.cpp.o > CMakeFiles/plplotd.dir/__/drivers/wxwidgets_dc.cpp.o > CMakeFiles/plplotd.dir/__/drivers/wxwidgets_gc.cpp.o' getting put into > libplplotd and not libplplotcxxd? So the other languages can output to wx* > devices? It's not really a driver though, correct? I never got a response to this. Comments, please? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Orion P. <or...@co...> - 2012-01-04 19:01:21
Attachments:
plplot-libs.patch
|
On 01/04/2012 11:29 AM, Alan W. Irwin wrote: > Hi Orion: > > Sorry your previous post fell through the cracks. I think Andrew is the > best guy to evaluate your patch so I won't comment on that, but > I will respond to two of your questions not involving the patch. > > On 2012-01-04 09:12-0700 Orion Poplawski wrote: > >>> plplot-ocaml.i686: E: binary-or-shlib-defines-rpath >>> /usr/lib/ocaml/stublibs/dllplplot_stubs.so ['/usr/lib/ocaml', >>> '/builddir/build/BUILD/plplot-5.9.9/fedora/src'] >>> plplot-ocaml.i686: E: binary-or-shlib-defines-rpath >>> /usr/lib/ocaml/stublibs/dllplcairo_stubs.so ['/usr/lib', >>> '/builddir/build/BUILD/plplot-5.9.9/fedora/src'] >>> >>> Anyone know why the rpaths aren't being removed on install? > > I have just made a change (revision 12117) which is untested, but > which I think should fix this. > Well, not sure if this is the cause, but: 10: Testing front-end ocaml 10: x01ocaml 10: /builddir/build/BUILD/plplot-5.9.9/fedora/examples/ocaml/x01ocaml: error while loading shared libraries: libplplotd.so.11: cannot open shared object file: No such file or directory 10/17 Test #10: examples_ocaml ...................***Failed 0.04 sec >>> >>> Trying to build with the attached patch though I get this: >>> >>> /usr/lib/ccache/gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >>> -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom >>> -fasynchronous-unwind-tables CMakeFiles/plserver.dir/plserver.c.o -o >>> plserver >>> -rdynamic ../../src/libplplotd.so.11.0.0 ../tcl/libplplottcltkd.so.9.2.0 >>> -ltk >>> -ltcl ../../src/libplplotd.so.11.0.0 >>> >>> -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.9/fedora/src:/builddir/build/BUILD/plplot-5.9.9/fedora/bindings/tcl:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/qsastime: >>> >>> -Wl,-rpath-link,/builddir/build/BUILD/plplot-5.9.9/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.9/fedora/lib/qsastime:/builddir/build/BUILD/plplot-5.9.9/fedora/bindings/tcl >>> >>> ../../src/libplplotd.so.11.0.0: undefined reference to >>> `agg::font_engine_freetype_base::hinting(bool)' >>> .... >>> ../../src/libplplotd.so.11.0.0: undefined reference to >>> `plD_dispatch_init_tek4107f' >>> >>> >>> Now, why is >>> 'CMakeFiles/plplotd.dir/__/drivers/wxwidgets_agg.cpp.oCMakeFiles/plplotd.dir/__/drivers/wxwidgets.cpp.o >>> CMakeFiles/plplotd.dir/__/drivers/wxwidgets_app.cpp.o >>> CMakeFiles/plplotd.dir/__/drivers/wxwidgets_dc.cpp.o >>> CMakeFiles/plplotd.dir/__/drivers/wxwidgets_gc.cpp.o' getting put into >>> libplplotd and not libplplotcxxd? So the other languages can output to wx* >>> devices? It's not really a driver though, correct? > > I assume you are building with the cmake option > -DENABLE_DYNDRIVERS=OFF. In that special case, the device drivers are not > shared objects which are dynamically loaded by the libplplot as for > the usual (default) case. Instead, for this special case all drivers > (whether C or C++) are made part of the plplot library and called > directly as needed as part of the services provided by that (expanded) > library. wxwidgets*.cpp.o are all compiled objects which are part of > the wxwidgets device driver. So the above seems fine to me. Thanks - I hadn't noticed that my FindLTDL.cmake patch was not setting LTDL_FOUND and so ENABLE_DYNDRIVERS was being set to off. I've updated my libs patch. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |