From: Rafael L. <lab...@ps...> - 2003-03-14 14:50:28
|
* Christophe TROESTLER <deb...@ti...> [2003-03-14 14:49]: > When I try to compile the "c" examples with "make" I get > > plplot_libtool --mode=link gcc x01c.c -I/usr/include/plplot -L/usr/lib -lplplotd -o x01c > plplot_libtool: link: cannot find the library `/usr/lib/libqhull.la' > make: *** [x01c] Error 1 > > What is the matter? I got > > ii libplplot-dev 5.2.0.cvs.20030307-1 > ii libplplot5 5.2.0.cvs.20030307-1 Scientific plotting library > ii plplot-doc 5.2.0.cvs.20030307-1 > ii plplot-gd 5.2.0.cvs.20030307-1 > ii plplot-tcl 5.2.0.cvs.20030307-1 > ii plplot-xwin 5.2.0.cvs.20030307-1 > ii libqhull4 2002.1-3 Calculate convex hulls and related structure > > installed, but they do not contain anything like libqhull.la ! > ^^ Short answer: apt-get install libqhull-dev (Oh, I love Debian! :-). Long answer: This is a bad side-effect of using plplot_libtool, instead of a full-fledged solution with the right libraries put in the Makefile. The problem comes from here: $ grep libqhull /usr/lib/libplplotd.la dependency_libs='/usr/lib/libfreetype.la -lz /usr/lib/libcsa.la /usr/lib/libnn.la /usr/lib/libqhull.la -lm -ldl' I may try to find a way to force the use of "-lqhull" instead of "/usr/lib/libqhull.la" in that file, because libqhull is not provided by the PLplot pakcage. Same thing for -lfreetype. I dunno if this is possible with libtool, but I will look at it. Otherwise, I will probably add a dependency on libqhull-dev and libfreetype6-dev to libplplot-dev. For now, since you are doing compilation (i.e., development) it is appropriate to install the libqhull-dev package, as suggested in the short answer above. Install also libfreetype6-dev, just in case. Last comment: The next time you find a problem in a Debian package (specially if it is only related to the Debian packages themselves), please send a bug report to the Debian BTS (Bug Tracking System). You will always be able to Cc: to plplot-devel, if you wish. If you do not know what I am talking about: apt-get install reportbug -- Rafael |
From: <jc...@fe...> - 2003-03-14 15:38:14
|
On Friday 14 March 2003 14:50, Rafael Laboissiere wrote: | * Christophe TROESTLER <deb...@ti...> [2003-03-14 14:49]: | > When I try to compile the "c" examples with "make" I get | > | > plplot_libtool --mode=link gcc x01c.c -I/usr/include/plplot | > -L/usr/lib -lplplotd -o x01c plplot_libtool: link: cannot find the | > library `/usr/lib/libqhull.la' make: *** [x01c] Error 1 | > | > What is the matter? I got | > | > ii libplplot-dev 5.2.0.cvs.20030307-1 | > ii libplplot5 5.2.0.cvs.20030307-1 Scientific plotting | > library ii plplot-doc 5.2.0.cvs.20030307-1 | > ii plplot-gd 5.2.0.cvs.20030307-1 | > ii plplot-tcl 5.2.0.cvs.20030307-1 | > ii plplot-xwin 5.2.0.cvs.20030307-1 | > ii libqhull4 2002.1-3 Calculate convex hulls and related | > structure | > | > installed, but they do not contain anything like libqhull.la ! | > ^^ | | Short answer: apt-get install libqhull-dev (Oh, I love Debian! :-). | | Long answer: This is a bad side-effect of using plplot_libtool, | instead of a full-fledged solution with the right libraries put in | the Makefile. The problem comes from here: | | $ grep libqhull /usr/lib/libplplotd.la | dependency_libs='/usr/lib/libfreetype.la -lz /usr/lib/libcsa.la | /usr/lib/libnn.la /usr/lib/libqhull.la -lm -ldl' | | I may try to find a way to force the use of "-lqhull" instead of | "/usr/lib/libqhull.la" in that file, because libqhull is not provided | by the PLplot pakcage. Same thing for -lfreetype. I dunno if this | is possible with libtool, but I will look at it. But won't this happens in other non-debian systems that have qhull/freetype installed as archive and not shared libraries? And even if a shared library exists but it was not built with libtool? The configure test that checks for the presence of qhull just checks that a program can be compiled with -lqhull, it does not check if it is a shared/archive library. If latter in the configure process -lqhull is replaced with <absolute_path>/libqhull.la that will break the make. Does the current plplot configure scheme address this issue? I have only tested with shared libs. Joao PS-One of the reasons why I want to be able to build the plplot docbook is to be able to "make dist" in order to test this issue in other systems. | | Otherwise, I will probably add a dependency on libqhull-dev and | libfreetype6-dev to libplplot-dev. For now, since you are doing | compilation (i.e., development) it is appropriate to install the | libqhull-dev package, as suggested in the short answer above. | Install also libfreetype6-dev, just in case. | | Last comment: The next time you find a problem in a Debian package | (specially if it is only related to the Debian packages themselves), | please send a bug report to the Debian BTS (Bug Tracking System). | You will always be able to Cc: to plplot-devel, if you wish. If you | do not know what I am talking about: | | apt-get install reportbug |
From: Rafael L. <lab...@ps...> - 2003-03-14 16:08:45
|
* João Cardoso <jc...@fe...> [2003-03-14 15:36]: > But won't this happens in other non-debian systems that have > qhull/freetype installed as archive and not shared libraries? And even if a > shared library exists but it was not built with libtool? Oh, I guess you are confused here. *.la files are _not_ static libraries. Neither are they shared libs. Actually, they are ... shell scripts (!!!) It only makes sense to use *.la files as arguments of libtool (or, in our case, plplot_libtool). I dislike the idea of using that script (plplot_libtool) to compile the examples, but Alan seems to have strong arguments in favor of it, mainly related to portability. > The configure test that checks for the presence of qhull just checks > that a program can be compiled with -lqhull, it does not check if it is > a shared/archive library. If latter in the configure process -lqhull > is replaced with <absolute_path>/libqhull.la that will break the make. No, configure never replaces -lqhull by <absolute_path>/libqhull.la. This is done internally by libtool when generating the libplplot{d}.la file (look at the line starting with "dependency_libs="). See below. > Does the current plplot configure scheme address this issue? I have only > tested with shared libs. This is not a matter of shared vs. static libraries, as I pointed out above. At any rate, this will not be a real problem, since if the user does not have libqhull.la installed in her system, then "-lqhull" gets inserted into libplplot{d}.la. To be convinced, just do it by yourself: $ cd /usr/lib $ mv libqhull.la libqhull.la-save $ cd ~/plplot-build/src $ rm libplplotd.la $ make > /dev/null $ grep dependency_libs libplplotd.la dependency_libs='/usr/lib/libfreetype.la -lz /home/rafael/plplot-build/lib/csa/libcsa.la /home/rafael/devel/plplot-build/lib/nn/libnn.la -lqhull -lm -ldl' ^^^^^^^ $ cd /usr/lib $ mv libqhull.la-save libqhull.la $ cd ~/plplot-build/src $ rm libplplotd.la $ make > /dev/null $ grep dependency_libs libplplotd.la dependency_libs='/usr/lib/libfreetype.la -lz /home/rafael/plplot-build/lib/csa/libcsa.la /home/rafael/devel/plplot-build/lib/nn/libnn.la /usr/lib/libqhull.la -lm -ldl' ^^^^^^^^^^^^^^^^^^^^ -- Rafael |
From: <jc...@fe...> - 2003-03-14 17:27:55
Attachments:
nantest.c
|
On Friday 14 March 2003 16:08, Rafael Laboissiere wrote: | * Jo=E3o Cardoso <jc...@fe...> [2003-03-14 15:36]: | > But won't this happens in other non-debian systems that have | > qhull/freetype installed as archive and not shared libraries? And | > even if a shared library exists but it was not built with libtool? | | Oh, I guess you are confused here. *.la files are _not_ static | libraries. Neither are they shared libs. Actually, they are ... | shell scripts (!!!) Yes, I have look at it. =2E.. | At any rate, this will not be a real problem, since if the user does | not have libqhull.la installed in her system, then "-lqhull" gets | inserted into libplplot{d}.la. To be convinced, just do it by | yourself: I believe you! I'm (was?) concerned with the qhull issue as I tested it only in linux,=20 and I don't know what will happen in other systems. You are the one=20 that religiously :) believe in libtool, not me :) But I still have doubts with nn/csa, because of NaN issues. I'm thinking in posting a RFC in the general list, asking for people=20 with non linux system to test a test program, that I attach. Under OSF/alpha, it must be compiled as gcc -mieee nantest.c -o nantest -lm or, using the native compiler, cc -ieee nantest.c -o nantest -lm Under linux, a plain gcc ... -lm will do the work, although adding the=20 =2Dmieee-fp flag is the recomended approach. The problem is how will solaris, aix, dos, etc behave. Do any of you=20 have classical unix systems where you can try it, either with gcc or=20 the native C compiler? This is the program output: [jcard@feup] ./nantest=20 GNUC, LITTLE_ENDIAN x=3Dnan x+1=3Dnan, z=3Dnan NaN detected Thanks, Joao |
From: Rafael L. <lab...@ps...> - 2003-03-14 18:56:50
|
* João Cardoso <jc...@fe...> [2003-03-14 17:26]: > But I still have doubts with nn/csa, because of NaN issues. > I'm thinking in posting a RFC in the general list, asking for people > with non linux system to test a test program, that I attach. > > Under OSF/alpha, it must be compiled as > > gcc -mieee nantest.c -o nantest -lm > > or, using the native compiler, > > cc -ieee nantest.c -o nantest -lm > > Under linux, a plain gcc ... -lm will do the work, although adding the > -mieee-fp flag is the recomended approach. Do you wish a new configure check to add the necessary flags for OSF/Alpha (or other systems)? -- Rafael |
From: Joao C. <jc...@fe...> - 2003-03-14 20:01:39
|
On Friday 14 March 2003 18:56, Rafael Laboissiere wrote: > * Jo=E3o Cardoso <jc...@fe...> [2003-03-14 17:26]: > > But I still have doubts with nn/csa, because of NaN issues. > > I'm thinking in posting a RFC in the general list, asking for people > > with non linux system to test a test program, that I attach. > > > > Under OSF/alpha, it must be compiled as > > > > gcc -mieee nantest.c -o nantest -lm > > > > or, using the native compiler, > > > > cc -ieee nantest.c -o nantest -lm > > > > Under linux, a plain gcc ... -lm will do the work, although adding the > > -mieee-fp flag is the recomended approach. > > Do you wish a new configure check to add the necessary flags for OSF/Alpha > (or other systems)? They are already there... but when new systems are know, it might be=20 necessary. Please check in sysloc.in for mieee-fp and correct it so it becomes "The Ri= ght=20 Way To Do It" (TM - Rafael :) Joao |
From: Rafael L. <lab...@ps...> - 2003-03-14 21:48:23
|
* Joao Cardoso <jc...@fe...> [2003-03-14 19:58]: > Please check in sysloc.in for mieee-fp and correct it so it becomes "The > Right Way To Do It" (TM - Rafael :) I am sorry, but in this case I do not now the Right Way (TM). Even in the GNU Autoconf Macro Archive (http://www.gnu.org/software/ac-archive/) there seems to be nothing regarding the cross-platform setting of the ieee compilation flag. In any case, the code that you inserted in sysloc.in with the settings of CFLAGS looks correct to me. Your idea of sending a RFC to plplot-general is a good one. Go ahead. -- Rafael |
From: Rafael L. <lab...@ps...> - 2003-03-15 00:28:54
|
* Rafael Laboissiere <lab...@ps...> [2003-03-14 22:48]: > * Joao Cardoso <jc...@fe...> [2003-03-14 19:58]: > > > Please check in sysloc.in for mieee-fp and correct it so it becomes "The > > Right Way To Do It" (TM - Rafael :) > > I am sorry, but in this case I do not now the Right Way (TM). Even in the > GNU Autoconf Macro Archive (http://www.gnu.org/software/ac-archive/) there > seems to be nothing regarding the cross-platform setting of the ieee > compilation flag. I searched a little bit further and found the excerpt below in the configure.in file of the GSL project (http://www.gnu.org/software/gsl/). This autoconf code is doing pretty much the same thing as your code in sysloc.in, besides an compilation exercise to check if the flags are really accepted in the alpha architecture. The fact that the code below only acts on CFLAGS for the alpha architecture is a good indication that your code in sysloc.in should work for all the other architectures, since they do not seem to need special treatment regarding the ieee flag. -- Rafael AC_MSG_CHECKING([for IEEE-conformance compiler flags]) save_cflags="$CFLAGS" case "$host" in alpha*-*-*) if test X"$GCC"= Xyes ; then ieee_alpha_options='-mieee' CFLAGS="$ieee_alpha_options $CFLAGS" else # This assumes Compaq's C compiler, which is probably # a pretty bad assumption. Improvements welcome. ieee_alpha_options='-ieee' CFLAGS="$ieee_alpha_options $CFLAGS" fi # # now see if the option we think should be accepted actually is # AC_TRY_COMPILE( ,[ int foo; ],[ AC_MSG_RESULT([$ieee_alpha_options]) dnl dnl after the check is over, CFLAGS will become save_cflags, dnl which has just acquired the additional flag. dnl save_cflags="$CFLAGS" ],[ AC_MSG_RESULT([unknown!]) AC_MSG_WARN( [I don't know how to enable full IEEE mode with your compiler] ) ] ) dnl here ends our AC_TRY_COMPILE ;; *) AC_MSG_RESULT([none]) ;; esac # Now restore our (possibly augmented) CFLAGS. CFLAGS="$save_cflags" |
From: Joao C. <jc...@fe...> - 2003-03-15 01:19:58
|
On Saturday 15 March 2003 00:28, Rafael Laboissiere wrote: > * Rafael Laboissiere <lab...@ps...> [2003-03-14 22:48]: > > * Joao Cardoso <jc...@fe...> [2003-03-14 19:58]: > > > Please check in sysloc.in for mieee-fp and correct it so it becomes > > > "The Right Way To Do It" (TM - Rafael :) > > > > I am sorry, but in this case I do not now the Right Way (TM). Even in > > the GNU Autoconf Macro Archive (http://www.gnu.org/software/ac-archive/) > > there seems to be nothing regarding the cross-platform setting of the > > ieee compilation flag. > > I searched a little bit further and found the excerpt below in the > configure.in file of the GSL project (http://www.gnu.org/software/gsl/). > This autoconf code is doing pretty much the same thing as your code in > sysloc.in, besides an compilation exercise to check if the flags are really > accepted in the alpha architecture. hmm, I would like a better test, not just that the flag is accepted. > > The fact that the code below only acts on CFLAGS for the alpha architecture > is a good indication that your code in sysloc.in should work for all the > other architectures, since they do not seem to need special treatment > regarding the ieee flag. Well, I will trust them. Also, Octave deals with that issue the same way. If GSL copied the settings from Octave (I think Octave is older), and we now trust them both, who shall we blame in case we are wrong? we of course ;-) Thanks, Joao |
From: Rafael L. <lab...@ps...> - 2003-03-15 10:03:09
|
* Joao Cardoso <jc...@fe...> [2003-03-15 01:16]: > On Saturday 15 March 2003 00:28, Rafael Laboissiere wrote: > > I searched a little bit further and found the excerpt below in the > > configure.in file of the GSL project (http://www.gnu.org/software/gsl/). > > This autoconf code is doing pretty much the same thing as your code in > > sysloc.in, besides an compilation exercise to check if the flags are really > > accepted in the alpha architecture. > > hmm, I would like a better test, not just that the flag is accepted. Do you wiush that the compilation exercise be introduced in our configure.ac? I can do it (but not test it fully, since I have no access to alpha machines). -- Rafael |
From: Joao C. <jc...@fe...> - 2003-03-15 23:23:44
|
On Saturday 15 March 2003 10:02, Rafael Laboissiere wrote: > * Joao Cardoso <jc...@fe...> [2003-03-15 01:16]: > > On Saturday 15 March 2003 00:28, Rafael Laboissiere wrote: > > > I searched a little bit further and found the excerpt below in the > > > configure.in file of the GSL project > > > (http://www.gnu.org/software/gsl/). This autoconf code is doing pretty > > > much the same thing as your code in sysloc.in, besides an compilation > > > exercise to check if the flags are really accepted in the alpha > > > architecture. > > > > hmm, I would like a better test, not just that the flag is accepted. > > Do you wiush that the compilation exercise be introduced in our > configure.ac? I can do it (but not test it fully, since I have no access > to alpha machines). It would be nice. The following program is a minimal test that does not guarantees that nn/csa and x21c.c will run OK. It tests a necessary but not sufficient condition. The other longer program I posted tests for sufficiency. #include <math.h> main() { double x; x = sqrt(-1.); if (x == x) return 1; return 0; } On a alpha/OSF: bash-2.01$ cc -ieee po.c -o po -lm && if ./po; then echo yes; else echo no; fi yes bash-2.01$ cc po.c -o po -lm && if ./po; then echo yes; else echo no; fi no bash-2.01$ gcc po.c -o po -lm && if ./po; then echo yes; else echo no; fi no bash-2.01$ gcc -mieee po.c -o po -lm && if ./po; then echo yes; else echo no; fi yes On linux: jcard@jcard:~> gcc po.c -o po -lm && if ./po; then echo yes; else echo no; fi yes jcard@jcard:~> gcc -mieee-fp po.c -o po -lm && if ./po; then echo yes; else echo no; fi yes On linux it does not seems to make a difference, but -mieee-fp is recomended. Joao |
From: Christophe T. <deb...@ti...> - 2003-03-14 16:19:13
|
On Fri, 14 Mar 2003, Rafael Laboissiere <lab...@ps...> wrote: > > Short answer: apt-get install libqhull-dev (Oh, I love Debian! :-). `-> me too :-) Thanks for your quick answer. > Otherwise, I will probably add a dependency on libqhull-dev and > libfreetype6-dev to libplplot-dev. Yes; that's why I was puzzled since I got libplplot-dev installed. > Last comment: The next time you find a problem in a Debian package > (specially if it is only related to the Debian packages themselves), > please send a bug report to the Debian BTS (Bug Tracking System) Will do -- sorry for cluttering the list. ChriS |
From: Rafael L. <lab...@ps...> - 2003-03-14 17:01:05
|
* Christophe TROESTLER <deb...@ti...> [2003-03-14 17:21]: > On Fri, 14 Mar 2003, Rafael Laboissiere <lab...@ps...> wrote: > > Last comment: The next time you find a problem in a Debian package > > (specially if it is only related to the Debian packages themselves), > > please send a bug report to the Debian BTS (Bug Tracking System) > > Will do -- sorry for cluttering the list. No problem. Next time, if you are not sure where the problem comes from (upstream or Debian packaging), send a Cc: to plplot-devel. -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-03-14 17:27:59
|
On Fri, 14 Mar 2003, Rafael Laboissiere wrote: > Long answer: This is a bad side-effect of using plplot_libtool, instead of a > full-fledged solution with the right libraries put in the Makefile. NO. You keep forgetting that libtool is a configured script that is adjusted exactly (and only) for the build system. See below. > The > problem comes from here: > > $ grep libqhull /usr/lib/libplplotd.la > dependency_libs='/usr/lib/libfreetype.la -lz /usr/lib/libcsa.la > /usr/lib/libnn.la /usr/lib/libqhull.la -lm -ldl' > > I may try to find a way to force the use of "-lqhull" instead of > "/usr/lib/libqhull.la" in that file, because libqhull is not provided by the > PLplot pakcage. Same thing for -lfreetype. I dunno if this is possible > with libtool, but I will look at it. Do NOT do this. I am surprised I have to go into libtool advocacy mode here with you on this. Our joint experience is it usually does exactly the right thing, and that proves to be the case this time as well. It simply is configured to do the right thing on the build system. In my case (Debian woody) I have an older qhull which was not built with libtool so there is no libqhull.la. But libtool is configured appropriately for that situation on my system. grep qhull /usr/local/plplot_at/lib/libplplotd.la dependency_libs=' /usr/lib/libfreetype.la /usr/local/plplot_at/lib/libcsa.la /usr/local/plplot_at/lib/libnn.la -lqhull -lm -ldl' Note in this case -lqhull is used. So the linking will be fine for all cases. Remember, libtool (and therefore the local copy of that script, plplot-libtool) is configured just for the build system so you cannot generalize the result on one system to what will happen on others. > > Otherwise, I will probably add a dependency on libqhull-dev and > libfreetype6-dev to libplplot-dev. This is the correct approach. If the user wants to build the examples he will obviously need libplplot-dev which will bring in the rest of the required dev packages. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <lab...@ps...> - 2003-03-14 18:54:35
|
* Alan W. Irwin <ir...@be...> [2003-03-14 09:26]: > On Fri, 14 Mar 2003, Rafael Laboissiere wrote: > > > Long answer: This is a bad side-effect of using plplot_libtool, instead of a > > full-fledged solution with the right libraries put in the Makefile. > > NO. You keep forgetting that libtool is a configured script that is > adjusted exactly (and only) for the build system. See below. Yes, this ideal situation only happens when the user build himself both libqhull and libplplot in the same system and never removed the libqhull.la file. A mismatch happened with my Debian packages, as reported by Christophe. So, the bad side effect may and _does_ happen in some cases. I already decided to change the libplplot-dev package dependencies, so there will be no problem. But there is another reason we need an alternative to using the plplot_libtool script. Imagine that in the future somebody writes an application that should link againt the PLplot library. How will this person configure her software in order to get the right libraries and cflags options? For now, this is easy to do using pkg-config: $ pkg-config plplot --cflags -DPL_DOUBLE $ pkg-config plplot --libs -lplplotd -lfreetype Notice that the results are still probably incorrect, but I have plans to fix that. > > The > > problem comes from here: > > > > $ grep libqhull /usr/lib/libplplotd.la > > dependency_libs='/usr/lib/libfreetype.la -lz /usr/lib/libcsa.la > > /usr/lib/libnn.la /usr/lib/libqhull.la -lm -ldl' > > > > I may try to find a way to force the use of "-lqhull" instead of > > "/usr/lib/libqhull.la" in that file, because libqhull is not provided by the > > PLplot pakcage. Same thing for -lfreetype. I dunno if this is possible > > with libtool, but I will look at it. > > Do NOT do this. I am surprised I have to go into libtool advocacy mode here > with you on this. Are you trying to evangelize the priest? :-) Joao just wrote the following, referring to me: * Joao Cardoso <jc...@fe...> [2003-03-14 17:26]: > [...] You are the one that religiously :) believe in libtool, not me :) * Alan W. Irwin <ir...@be...> [2003-03-14 09:26]: > Our joint experience is it usually does exactly the right thing, and that > proves to be the case this time as well. It simply is configured to do the > right thing on the build system. In my case (Debian woody) I have an older > qhull which was not built with libtool so there is no libqhull.la. But > libtool is configured appropriately for that situation on my system. > > grep qhull /usr/local/plplot_at/lib/libplplotd.la > dependency_libs=' /usr/lib/libfreetype.la /usr/local/plplot_at/lib/libcsa.la > /usr/local/plplot_at/lib/libnn.la -lqhull -lm -ldl' > > Note in this case -lqhull is used. Oh, you just replicated the analysis that I already send to the mailing list in replying to Joao... Well, redundancy is always good to have things really assimilated by the others. > So the linking will be fine for all cases. Remember, libtool (and > therefore the local copy of that script, plplot-libtool) is configured just > for the build system so you cannot generalize the result on one system to > what will happen on others. I never did this generalization... > > Otherwise, I will probably add a dependency on libqhull-dev and > > libfreetype6-dev to libplplot-dev. > > This is the correct approach. If the user wants to build the examples he > will obviously need libplplot-dev which will bring in the rest of the > required dev packages. This is what I already did in my local cvs tree. Will be in the upcoming Debian release. -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-03-14 21:19:49
|
On Fri, 14 Mar 2003, Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2003-03-14 09:26]: > > > On Fri, 14 Mar 2003, Rafael Laboissiere wrote: > > > > > Long answer: This is a bad side-effect of using plplot_libtool, instead of a > > > full-fledged solution with the right libraries put in the Makefile. > > > > NO. You keep forgetting that libtool is a configured script that is > > adjusted exactly (and only) for the build system. See below. > > Yes, this ideal situation only happens when the user build himself both > libqhull and libplplot in the same system and never removed the libqhull.la > file. No. Joao's, your, and my systems are the counter-examples here. None of us (I assume) built libqhull. Instead, it was supplied as a binary with and without libqhull.la on our various systems, yet for that variety of situations plplot_libtool is working fine. Essentially the user should not go wrong if they stick with the system where they built plplot and use the plplot_libtool script configured for that system. It is a different story if a binary package of plplot is provided, but that is a controlled environment where you know exactly what was on the build machine, and you can force the user to also install the same. In that case if you get the libplplot-dev package dependencies correct, then again the user cannot go wrong using plplot_libtool. > A mismatch happened with my Debian packages, as reported by > Christophe. So, the bad side effect may and _does_ happen in some cases. I > already decided to change the libplplot-dev package dependencies, so there > will be no problem. > No. Actually, the problem was that Christophe had not installed the dev packages, and the problem went away when he did so. So that definitely does not prove your case that something must be wrong with plplot_libtool. To sum this up, there are no demonstrated problems with plplot_libtool either when the user is building plplot or in the binary plplot package case when the dev package dependencies are correct. Thus, "If it ain't broke don't fix it." Will you quit complaining about plplot_libtool if I change its name to plplot-libtool? ;-) (To explain the joke to the rest of you, Rafael has told me in the past that he hates underscores and loves hyphens.) Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Joao C. <jc...@fe...> - 2003-03-15 01:24:45
|
On Friday 14 March 2003 21:18, Alan W. Irwin wrote: > On Fri, 14 Mar 2003, Rafael Laboissiere wrote: > > * Alan W. Irwin <ir...@be...> [2003-03-14 09:26]: > > > On Fri, 14 Mar 2003, Rafael Laboissiere wrote: > > > > Long answer: This is a bad side-effect of using plplot_libtool, > > > > instead of a full-fledged solution with the right libraries put in > > > > the Makefile. > > > > > > NO. You keep forgetting that libtool is a configured script that is > > > adjusted exactly (and only) for the build system. See below. > > > > Yes, this ideal situation only happens when the user build himself both > > libqhull and libplplot in the same system and never removed the > > libqhull.la file. > > No. Joao's, your, and my systems are the counter-examples here. None of > us (I assume) built libqhull. I dont know what you are talking about, but I had to build qhull from source. Of course this is no argument to none of you, Alan and Rafael, because qhull "configure" was written by Rafael :) Joao |