You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(58) |
Nov
(95) |
Dec
(55) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(205) |
Feb
(106) |
Mar
(36) |
Apr
(25) |
May
(34) |
Jun
(36) |
Jul
(161) |
Aug
(66) |
Sep
(100) |
Oct
(62) |
Nov
(77) |
Dec
(172) |
2003 |
Jan
(101) |
Feb
(202) |
Mar
(191) |
Apr
(97) |
May
(27) |
Jun
(21) |
Jul
(16) |
Aug
(55) |
Sep
(155) |
Oct
(166) |
Nov
(19) |
Dec
(134) |
2004 |
Jan
(569) |
Feb
(367) |
Mar
(81) |
Apr
(62) |
May
(124) |
Jun
(77) |
Jul
(85) |
Aug
(80) |
Sep
(66) |
Oct
(42) |
Nov
(20) |
Dec
(133) |
2005 |
Jan
(192) |
Feb
(143) |
Mar
(183) |
Apr
(128) |
May
(136) |
Jun
(18) |
Jul
(22) |
Aug
(33) |
Sep
(20) |
Oct
(12) |
Nov
(80) |
Dec
(44) |
2006 |
Jan
(42) |
Feb
(38) |
Mar
(17) |
Apr
(112) |
May
(220) |
Jun
(67) |
Jul
(96) |
Aug
(214) |
Sep
(104) |
Oct
(67) |
Nov
(150) |
Dec
(103) |
2007 |
Jan
(111) |
Feb
(50) |
Mar
(113) |
Apr
(19) |
May
(32) |
Jun
(34) |
Jul
(61) |
Aug
(103) |
Sep
(75) |
Oct
(99) |
Nov
(102) |
Dec
(40) |
2008 |
Jan
(86) |
Feb
(56) |
Mar
(104) |
Apr
(50) |
May
(45) |
Jun
(64) |
Jul
(71) |
Aug
(147) |
Sep
(132) |
Oct
(176) |
Nov
(46) |
Dec
(136) |
2009 |
Jan
(159) |
Feb
(136) |
Mar
(188) |
Apr
(189) |
May
(166) |
Jun
(97) |
Jul
(160) |
Aug
(235) |
Sep
(163) |
Oct
(46) |
Nov
(99) |
Dec
(54) |
2010 |
Jan
(104) |
Feb
(121) |
Mar
(153) |
Apr
(75) |
May
(138) |
Jun
(63) |
Jul
(61) |
Aug
(27) |
Sep
(93) |
Oct
(63) |
Nov
(40) |
Dec
(102) |
2011 |
Jan
(52) |
Feb
(26) |
Mar
(61) |
Apr
(27) |
May
(33) |
Jun
(43) |
Jul
(37) |
Aug
(53) |
Sep
(58) |
Oct
(63) |
Nov
(67) |
Dec
(16) |
2012 |
Jan
(97) |
Feb
(34) |
Mar
(6) |
Apr
(18) |
May
(32) |
Jun
(9) |
Jul
(17) |
Aug
(78) |
Sep
(24) |
Oct
(101) |
Nov
(31) |
Dec
(7) |
2013 |
Jan
(44) |
Feb
(35) |
Mar
(59) |
Apr
(17) |
May
(29) |
Jun
(38) |
Jul
(48) |
Aug
(46) |
Sep
(74) |
Oct
(140) |
Nov
(94) |
Dec
(177) |
2014 |
Jan
(94) |
Feb
(74) |
Mar
(75) |
Apr
(63) |
May
(24) |
Jun
(1) |
Jul
(30) |
Aug
(112) |
Sep
(78) |
Oct
(137) |
Nov
(60) |
Dec
(17) |
2015 |
Jan
(128) |
Feb
(254) |
Mar
(273) |
Apr
(137) |
May
(181) |
Jun
(157) |
Jul
(83) |
Aug
(34) |
Sep
(26) |
Oct
(9) |
Nov
(24) |
Dec
(43) |
2016 |
Jan
(94) |
Feb
(77) |
Mar
(83) |
Apr
(19) |
May
(39) |
Jun
(1) |
Jul
(5) |
Aug
(10) |
Sep
(28) |
Oct
(34) |
Nov
(82) |
Dec
(301) |
2017 |
Jan
(53) |
Feb
(50) |
Mar
(11) |
Apr
(15) |
May
(23) |
Jun
(36) |
Jul
(84) |
Aug
(90) |
Sep
(35) |
Oct
(81) |
Nov
(13) |
Dec
(11) |
2018 |
Jan
(15) |
Feb
(4) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(6) |
Jul
(4) |
Aug
(13) |
Sep
(31) |
Oct
(4) |
Nov
(25) |
Dec
(64) |
2019 |
Jan
(7) |
Feb
(4) |
Mar
|
Apr
|
May
(13) |
Jun
(8) |
Jul
(16) |
Aug
(7) |
Sep
(27) |
Oct
(1) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(8) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(3) |
Oct
(2) |
Nov
(4) |
Dec
(3) |
2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
(9) |
Aug
(3) |
Sep
|
Oct
(8) |
Nov
(4) |
Dec
|
2022 |
Jan
|
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(8) |
2023 |
Jan
(6) |
Feb
|
Mar
(1) |
Apr
(2) |
May
(10) |
Jun
(7) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <jc...@fe...> - 2003-02-05 16:27:34
|
On Monday 03 February 2003 22:17, Alan W. Irwin wrote: | On Mon, 3 Feb 2003, Rafael Laboissiere wrote: | > > make[3]: Entering directory `/home/jcard/plplot/bindings/python' | > > python -o plplotcmodule_p_double.c -c++ -DPL_DOUBLE \ | > > plplotcmodule.i | > > Unknown option: -o | > | > No idea about this. Alan? | | The command should be | | $(SWIG) -python -o plplotcmodule_p_double.c -c++ -DPL_DOUBLE \ | plplotcmodule.i | | So I think his error message is caused because $(SWIG) is undefined | for him, but I don't know the root cause of that problem. One | possibility is the old autotools versions he is using. Another | possibility is he may have forgot to specify --enable-maintainer-mode | for his ./configure option. I don't know whether that is essential | or not after you have done a make | maintainer-clean, but I suspect it is. | | What happens, Joao, for the latest stable autotools versions, clean | PLplot checkout, and --enable-maintainer-mode? Now everything runs OK: > make maintainer-clean > ./bootstrap.sh=20 Running aclocal (GNU automake) 1.7.2... done Running libtoolize (GNU libtool) 1.4.3... done Running autoheader (GNU Autoconf) 2.57... done Running automake (GNU automake) 1.7.2... done Running autoconf (GNU Autoconf) 2.57... done > ./configure *without* the --enable-maintainer-mode =2E.. make[3]: Entering directory `/home/jcard/plplot/bindings/python' swig -python -o plplotcmodule_p_double.c -c++ -DPL_DOUBLE \ =2E.. Joao |
From: Rafael L. <lab...@ps...> - 2003-02-05 15:36:44
|
* João Cardoso <jc...@fe...> [2003-02-05 15:16]: > On Wednesday 05 February 2003 11:25, Rafael Laboissiere wrote: > | Update of /cvsroot/plplot/plplot/drivers > | In directory sc8-pr-cvs1:/tmp/cvs-serv16366/drivers > | > | Modified Files: > | Makefile.am pstex.c > | Log Message: > | Cleaned up the ps vs. pstex driver mess. When dyndrivers are > | enabled, the use of --enable-pstex imply now the inclusion of the > | ps.so driver module, enabling the ps and psc devices. > | > | On the other hand, when --enable-ps and --diasable-pstex are > | specified, the pstex.so driver module is not erroneously installed, > | as it used to be. > > BTW, this does not also happens with the xwin and tk driver? If I > disable xwin but enable the tk driver (not very likely), than the tk > driver will not work, as it needs xwin. The reverse works fine. Yes, a similar change has to be done for enable_tk and enable_xwin. Since I never use Tcl/Tk, I let fix this to the others. (Well, I never use pstex neither, but I do not feel myself comfortable in making changes to the Tcl/Tk part of PLplot.) -- Rafael |
From: Rafael L. <lab...@ps...> - 2003-02-05 15:32:40
|
[Errata. I am typing too fast...] * Rafael Laboissiere <lab...@ps...> [2003-02-05 16:19]: > drivers claim the same number, of of them will (randomly) get first in the ^^ *one* of them > This is way I see this sequence number as a kind of "priority level". ^^^ *why* -- Rafael |
From: Rafael L. <lab...@ps...> - 2003-02-05 15:29:57
|
* Alan W. Irwin <ir...@be...> [2003-02-05 06:59]: > I assume you are talking about your new code here. For the old code the > numbers had to be unique Not necessarily. In the old code, the entries were sorted using the seq filed of the PLDispatchtable entries using qsort. This means that, when two drivers claim the same number, of of them will (randomly) get first in the list. However, it is guaranteed that they will appear both before (above) drivers with greater (lesser) sequence numbers. This is way I see this sequence number as a kind of "priority level". > (and seqnum was 6 for the gnome driver). Right, I thought I had put "1" in the past. > Of course, that was a maintenance burden so if they just become non-unique > priority numbers now, that is a significant improvement. This is exactly the idea behind my last proposal. -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-02-05 15:01:16
|
On Wed, 5 Feb 2003, Rafael Laboissiere wrote: > > Also, with the second idea I think that the driver-ids (the magic numbers) > > can go away -- ah, no, for historical reasons the xwin driver must be > > number one, the tk driver number 2, etc. hmm, there is another solution for > > this but let discuss it latter. > > Please, notice that these magic number (seqnum) are not so "magic". They > only give a hint about how to order them. Think on them like "priority > level". BTW, the gnome driver also has seqnum = 1. I assume you are talking about your new code here. For the old code the numbers had to be unique (and seqnum was 6 for the gnome driver). Of course, that was a maintenance burden so if they just become non-unique priority numbers now, that is a significant improvement. 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: Alan W. I. <ir...@be...> - 2003-02-05 14:44:59
|
On Wed, 5 Feb 2003, Maurice LeBrun wrote: > I say move it (plbuf.c). [...] Be sure to mention where it came from & what version > in the first commit of the file in the new location. Done. 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-02-05 14:05:46
|
* Rafael Laboissiere <lab...@ps...> [2003-02-04 22:37]: > c) At build time (not configuration time), a small C program dlopen the > <driver>.c files, get the symbols described above and write the > associated device entries in <driver>.rc (or whichever name). Just to make things a bit more concrete, here is the design that I have in mind. I will take the ps.c driver as an example. The following global variables will be defined in the driver source: char* DEVICES_ps = "ps:psc"; char* DESCRIPTION_ps = "PostScript File (monochrome)"; int TYPE_ps = plDevType_FileOriented; int SEQNUM_ps = 29; char* SYMTAG_ps = "psm"; char* DESCRIPTION_psc = "PostScript File (color)"; int TYPE_psc = plDevType_FileOriented; int SEQNUM_psc = 30; char* SYMTAG_psc = "psc"; Of course, these variables should be used in the plD_dispatch_init_* functions. In the case of ps.c: ps_dispatch_init_helper( pdt, DESCRIPTION_ps, "ps", TYPE_ps, SEQNUM_ps, (plD_init_fp) plD_init_psm ); ps_dispatch_init_helper( pdt, DESCRIPTION_psc, "psc", TYPE_psc, SEQNUM_psc, (plD_init_fp) plD_init_psc ); This will insure that things are not defined twice in different places (like with the current DEVICE_INFO_* variable). The small C program that will generate the <driver>.rc file from the <driver>.la file, would do: (1) dlopen the module; (2) get the DEVICES_* symbol and parse its device components (in the ps.c exemple, that would be "ps" and "psc"); (3) for each one of the devices found, get the symbols DESCRIPTION_<dev>, TYPE_<dev>, SEQNUM_<dev>, and SYMTAG_<dev>; (4) create the temp file that is parsed by Geoff's code. (This could be improved along Joao's suggestion of creating a structure instead of writing the information in a temp file.) We have to decide first whether it is not worth abandoning the current approach and adopting this "cached info" approach above. There is also Joao's suggestion for dynamically building the drivers.db, but I am too lazy to implement that (and I am not sure it is a superior approach). What do you think? I accept suggestions for better variable names. -- Rafael |
From: Rafael L. <lab...@ps...> - 2003-02-05 12:32:39
|
* Rafael Laboissiere <lab...@ps...> [2003-02-05 12:23]: > drivers_DATA = $(drivers_LTLIBRARIES:.la=.rc) > %.rc: %.la get_drv_info > @echo get_drv_info $< $@ Please, take that "@echo" out. I used it for testing the idea here. It works, anyway. I guess I am typing too fast and posting without reading what I wrote... -- Rafael |
From: Rafael L. <lab...@ps...> - 2003-02-05 11:33:33
|
[ Sorry if this message is duplicated. I sent it originally to Joao only and tried to bounce it from my MUA. Since I did not receive it from the listserver, I am trying again, as a forward. BTW, why are the plplot-devel archives @ SF not accessible?] * Joao Cardoso <jc...@fe...> [2003-02-05 02:53]: > That's true, but the target should be to get a full-working 5.2.1, that > should be, in my opinion, a bug-correcting release. Introducing such stuff > can compromise it. But we have not defined what 5.2.1 should be, and I'm > too conservative. Well, my changes does not introduce new features to PLplot. BTW, they are transparent for the users and only slightly important for the developers (actually, I think my changes improve maintainability). > I have myself lots of new stuff, and I'm refraining myself to commit them. > I hope that 5.2.2 or even 5.3.0 follows shortly. If you are planning to do changes that will either destabilize the code or introduce new features like changes in the API, I think you should refrain yourself until 5.2.1 is out. > Ah, you use a tmp file just to reuse Geoff's code. But there is no reason to > not change that also latter, right? You got it. I have not against improving the code and putting all the information in a structure, that can also be cached in the <driver>.rc files. The important point here is that we should not have a unique file (like drivers.db) that contains the information about all available drivers. > > 1) Portability. I am using new libc functions (POSIX tmpfile, opendir, > > readdir and closedir). Although am I following the recommended > > procedure found in the Autoconf docs (i.e. using AC_HEADER_DIRENT and a > > couple of tests with HAVE_DIRENT_H), I am sure that there will be some > > weird system out there (MacIntosh, say) for which my code won't compile. > > If that happens, we have to port that part of the code. > > Don't create the file :) >From the smile, I guess you are joking. I did not get the joke, though... > > c) At build time (not configuration time), a small C program dlopen the > > <driver>.c files, > > You mean "open" and not dlopen(), right? No, I meant dlopen (lt_dlopenext, to be more precise). > No, you mean dlopen() the <driver>.so (I don't know the current suffix) Yes, I mistakenly wrote <driver>.c. > I prefer the full dynamic one, i.e., reading the already build drivers. I > don't think that performance will suffer. It is not only a matter of time performance, but I was wondering about hte fact that when all the module are dynamically loaded, all the libraries (tcl, gd, gnome, etc.) will be unnecessarily dynamically linked. I am just specutlating about this, though. > Do you have some figures or only feelings? I have no figures, but my feeling is that it does not affect performance at all. I have here: $ cat /proc/cpuinfo | egrep "^(model n|cpu M|bogo)" model name : Pentium III (Coppermine) cpu MHz : 929.842 bogomips : 1854.66 > Your second idea implies that the small program that scans the source files > [..] No, it would "scan" the <driver>.la files (see above). > [...] needs information from the configure step to know what drivers are > desired by the user and supported by the system. This complicates matters. Yes, the list of dynamic drivers is built at configure time and stored in the variable DYNAMIC_DRIVERS, which is passed to drivers/Makefile.am. However, there will no further complication in the build process. The following addition to drivers/Makefile.am should do the job: drivers_DATA = $(drivers_LTLIBRARIES:.la=.rc) %.rc: %.la get_drv_info @echo get_drv_info $< $@ Where the get_drv_info.c is the C program that I mentioned already. > With the first idea, by contrary, only already build drivers, i.e, user > desired and system supported, are scanned. If there is no drawback with this solution, I will adopt it (it is in CVS already). However, I would prefer a "info cached" approach. > Also, with the second idea I think that the driver-ids (the magic numbers) > can go away -- ah, no, for historical reasons the xwin driver must be > number one, the tk driver number 2, etc. hmm, there is another solution for > this but let discuss it latter. Please, notice that these magic number (seqnum) are not so "magic". They only give a hint about how to order them. Think on them like "priority level". BTW, the gnome driver also has seqnum = 1. > If performance is really an issue, then one could implements a mixing of > the two ideas: don't generate drivers.db at configure nor build time. At > run time if drivers.db does not exists, scan the drivers and build it. This > way the performance loss will only occurs once. If a new driver is latter > added to the directory (not probable, but possible, after all this is the > only advantage of dyndrivers), one could first compare the time-stamp of > all drivers versus the drivers.db file, and rebuild drivers.db if a driver > is more recent. Reading time-stamp is fast, I believe. This is a nice possibility, it is maybe the best solution, but someone has to implement it. It adds complexity to the code. Volunteers? ;-) -- Rafael |
From: Rafael L. <lab...@ps...> - 2003-02-05 11:25:44
|
* Joao Cardoso <jc...@fe...> [2003-02-05 02:09]: > No. I only remember that the pstex configuration changed a couple of times. > The pstex needs the ps driver, directly calling the ps driver entry points. > > If it works with Rafael changes, that's fine for me. For a quick test use > any C example and the scripts/pstex2eps script to generate an eps. I cleaned up this mess, see my last cvs commit. For dyndrivers, it seems that when pstex.so is dynopened, ps.so must be also be present in the drivers directory. I added the following lines to configure.ac: if test "$enable_dyndrivers" = yes -a "$enable_pstex" = yes ; then enable_ps=yes fi I also fixed the dependencies in drivers/Makefile.am and changed "ps" to "pstex" in DEVICE_INFO_pstex (pstex.c file). -- Rafael |
From: Rafael L. <lab...@ps...> - 2003-02-05 09:28:52
|
* Joao Cardoso <jc...@fe...> [2003-02-05 02:53]: > That's true, but the target should be to get a full-working 5.2.1, that > should be, in my opinion, a bug-correcting release. Introducing such stuff > can compromise it. But we have not defined what 5.2.1 should be, and I'm > too conservative. Well, my changes does not introduce new features to PLplot. BTW, they are transparent for the users and only slightly important for the developers (actually, I think my changes improve maintainability). > I have myself lots of new stuff, and I'm refraining myself to commit them. > I hope that 5.2.2 or even 5.3.0 follows shortly. If you are planning to do changes that will either destabilize the code or introduce new features like changes in the API, I think you should refrain yourself until 5.2.1 is out. > Ah, you use a tmp file just to reuse Geoff's code. But there is no reason to > not change that also latter, right? You got it. I have not against improving the code and putting all the information in a structure, that can also be cached in the <driver>.rc files. The important point here is that we should not have a unique file (like drivers.db) that contains the information about all available drivers. > > 1) Portability. I am using new libc functions (POSIX tmpfile, opendir, > > readdir and closedir). Although am I following the recommended > > procedure found in the Autoconf docs (i.e. using AC_HEADER_DIRENT and a > > couple of tests with HAVE_DIRENT_H), I am sure that there will be some > > weird system out there (MacIntosh, say) for which my code won't compile. > > If that happens, we have to port that part of the code. > > Don't create the file :) >From the smile, I guess you are joking. I did not get the joke, though... > > c) At build time (not configuration time), a small C program dlopen the > > <driver>.c files, > > You mean "open" and not dlopen(), right? No, I meant dlopen (lt_dlopenext, to be more precise). > No, you mean dlopen() the <driver>.so (I don't know the current suffix) Yes, I mistakenly wrote <driver>.c. > I prefer the full dynamic one, i.e., reading the already build drivers. I > don't think that performance will suffer. It is not only a matter of time performance, but I was wondering about hte fact that when all the module are dynamically loaded, all the libraries (tcl, gd, gnome, etc.) will be unnecessarily dynamically linked. I am just specutlating about this, though. > Do you have some figures or only feelings? I have no figures, but my feeling is that it does not affect performance at all. I have here: $ cat /proc/cpuinfo | egrep "^(model n|cpu M|bogo)" model name : Pentium III (Coppermine) cpu MHz : 929.842 bogomips : 1854.66 > Your second idea implies that the small program that scans the source files > [..] No, it would "scan" the <driver>.la files (see above). > [...] needs information from the configure step to know what drivers are > desired by the user and supported by the system. This complicates matters. Yes, the list of dynamic drivers is built at configure time and stored in the variable DYNAMIC_DRIVERS, which is passed to drivers/Makefile.am. However, there will no further complication in the build process. The following addition to drivers/Makefile.am should do the job: drivers_DATA = $(drivers_LTLIBRARIES:.la=.rc) %.rc: %.la get_drv_info @echo get_drv_info $< $@ Where the get_drv_info.c is the C program that I mentioned already. > With the first idea, by contrary, only already build drivers, i.e, user > desired and system supported, are scanned. If there is no drawback with this solution, I will adopt it (it is in CVS already). However, I would prefer a "info cached" approach. > Also, with the second idea I think that the driver-ids (the magic numbers) > can go away -- ah, no, for historical reasons the xwin driver must be > number one, the tk driver number 2, etc. hmm, there is another solution for > this but let discuss it latter. Please, notice that these magic number (seqnum) are not so "magic". They only give a hint about how to order them. Think on them like "priority level". BTW, the gnome driver also has seqnum = 1. > If performance is really an issue, then one could implements a mixing of > the two ideas: don't generate drivers.db at configure nor build time. At > run time if drivers.db does not exists, scan the drivers and build it. This > way the performance loss will only occurs once. If a new driver is latter > added to the directory (not probable, but possible, after all this is the > only advantage of dyndrivers), one could first compare the time-stamp of > all drivers versus the drivers.db file, and rebuild drivers.db if a driver > is more recent. Reading time-stamp is fast, I believe. This is a nice possibility, it is maybe the best solution, but someone has to implement it. It adds complexity to the code. Volunteers? ;-) -- Rafael |
From: Rafael L. <lab...@ps...> - 2003-02-05 09:27:40
|
* Maurice LeBrun <mj...@ga...> [2003-02-05 02:21]: > I say move it. It's been a while since any significant changes have been made > to it IIRC, but soon I have plans for it. And, one can always see the rev > history by going to the drivers dir and doing a 'cvs log' even if the file > has been cvs rm'ed. Be sure to mention where it came from & what version > in the first commit of the file in the new location. Alan, could you take care of this? -- Rafael |
From: Maurice L. <mj...@ga...> - 2003-02-05 08:22:56
|
Rafael Laboissiere writes: > Why are we waiting to do the move? The only drawback that I see is that we > will loose the commit history if we move the file, since braindead CVS does > not know how to move files in the repository tree. I say move it. It's been a while since any significant changes have been made to it IIRC, but soon I have plans for it. And, one can always see the rev history by going to the drivers dir and doing a 'cvs log' even if the file has been cvs rm'ed. Be sure to mention where it came from & what version in the first commit of the file in the new location. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Rafael L. <lab...@ps...> - 2003-02-05 08:16:59
|
* Alan W. Irwin <ir...@be...> [2003-02-04 15:11]: > Are you using "dlopen" in the generic sense here? The actual call should > be to lt_dlopenext, and you have to be careful of the argument (follow > exactly what I did with drvnam and drvspec so the file name comes out > exactly the same to get it to work cross-platform). Of course, I used the libltdl interface (lt_dl* functions). In particular, the modules are open with lt_dlopenext. > IIRC next.c is completely unmaintained and kept in CVS only as an > encouragment for somebody, someday, to get it going again. Okay. This is something that will be absent of the 5.2.1 tarball, thnaks to "make dist". > plbuf.c is not a driver in the traditional sense. I believe it is in the > wrong directory and should be put in src instead. It's code is put > directly into the libplplot library (see src/Makefile.am). Why are we waiting to do the move? The only drawback that I see is that we will loose the commit history if we move the file, since braindead CVS does not know how to move files in the repository tree. -- Rafael |
From: Joao C. <jc...@fe...> - 2003-02-05 02:56:48
|
On Tuesday 04 February 2003 21:37, Rafael Laboissiere wrote: > Preamble > =3D=3D=3D=3D=3D=3D=3D=3D > > The big recent cvs commit regarding the dyndrivers database was on the = top > of my TODO list. It is a necessary step towards clean > configuration/building and also packaging for Debian. > > I am not yet completely happy with my implementation, but my changes > (apparently) did not break PLplot. My simple test script succeeded, at > least. I am committing without previous discussion here because, as Al= an > uses to say, getting novelties in cvs HEAD is the best way to foster > discussions. That's true, but the target should be to get a full-working 5.2.1, that s= hould=20 be, in my opinion, a bug-correcting release. Introducing such stuff can compromise it. But we have not defined what 5.2.1 should be, and I'm too conservative. I have myself lots of new stuff, and I'm refraining myself to commit them= =2E I=20 hope that 5.2.2 or even 5.3.0 follows shortly. > > The Problem > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The way PLplot used to get information about the available devices prov= ided > by the dyndrivers was through the DATA_DIR/drivers.db file. This file = was > generated at configuration time and parsed when the library was > initialized. > > This approach has two drawbacks: > > 1) Information about the devices are scattered in different places (nam= ely > in the driver source file and in configure.ac). This is ugly and ma= y > result in unnecessary maintenance burden. > > 2) Since the list of available devices is hardcoded in the drivers.db i= t is > almost impossible to do clean packaging of Plplot. In Debian, for > instance, packaging is granular in order to reduce the dependencies: > plplot-xwin, plplot-tk, plplot-gd, etc. Users can install a subset = of > the available packages at will. However, they will always get the f= ull > list of available devices when plinit is called. That is not a crit= ical > problem, but annoying. > > > The Solution > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > I have elaborated a full fix for this problem, but I just committed an > intermediary solution for it. Here is how it works: > > 1) drivers.db does not exist anymore. > > 2) In each driver file, there is a global declaration like this: > > char* DEVICE_INFO_gd =3D "jpeg:JPEG file:0:gd:40:jpeg\n" > "png:PNG file:0:gd:39:png"; OK, but we need a registration text file, manually maintained, to guide n= ew=20 drivers writers on how to obtain (and register) new ids for the new drive= rs.=20 > > containing the entries that used to go into drivers.db. If a driver > provides more than one device, their entries must be separated by a > newline character ('\n'). > > 3) When the library is initialized, if dyndrivers are enabled, the driv= ers > directory is scanned for the *.la files. Each found driver is dlope= ned > and the DEVICE_INFO_<driver> symbol is read and put in a temporary f= ile. > > 4) This temporary file plays the role of the old drivers.db file. Why is the tmp file needed? Why not keep the collected info in an interna= l=20 structure? > Noticed that I did minimal changes to Geoff's code in plcore.c. In the > plInitDispatchTable function, I replaced the initial code (where the > drivers.db were scanned) by the scanning of the drivers directory descr= ibed > in point 3 above. Ah, you use a tmp file just to reuse Geoff's code. But there is no reason= to=20 not change that also latter, right? > Also, all references to drivers.db and DRIVERS_DB have disappeared from= the > sources. > > > Drawbacks and improvements > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > I see two potential problems with my approach: > > 1) Portability. I am using new libc functions (POSIX tmpfile, opendir, > readdir and closedir). Although am I following the recommended > procedure found in the Autoconf docs (i.e. using AC_HEADER_DIRENT and a > couple of tests with HAVE_DIRENT_H), I am sure that there will be some > weird system out there (MacIntosh, say) for which my code won't compile= =2E=20 > If that happens, we have to port that part of the code. Don't create the file :) > 2) With my approach, I have to open all and every module before using t= hem. > This may appear as a regression as regards the "cache file" approach > provided by the use of drivers.db. In terms of performance, with ou= r > current computer power, the overload is negligible. However, as I w= rote > above, my original design was much better, but harder to implement (= of > course). It looks like this: > > a) Forget about that entries a la drivers.db. > > b) In each driver file <driver>.c define symbols DEV_DESC_*, DEV_SEQ= _*, > DEV_TAG_*, etc. These symbols can be used when filling fields in > function plD_dispatch_init_<device>. This would further reduce t= he > maintenance problem due to duplication of information. > > c) At build time (not configuration time), a small C program dlopen = the > <driver>.c files, You mean "open" and not dlopen(), right? > get the symbols No, you mean dlopen() the <driver>.so (I don't know the current suffix) What do you really mean? Anyway, see bellow. > described above and write the > associated device entries in <driver>.rc (or whichever name). > > d) Those <driver>.rc are installed in the drivers directory, along w= ith > the <driver>.la and <driver>.so files. > > e) When PLplot is initialized, the <driver>.rc files are scanned. > > If I have some time before the 5.2.1 release, I will try to implemen= t > this idea. I prefer the full dynamic one, i.e., reading the already build drivers. I= =20 don't think that performance will suffer. Do you have some figures or onl= y =20 feelings? Your second idea implies that the small program that scans the source fil= es=20 needs information from the configure step to know what drivers are desire= d by=20 the user and supported by the system. This complicates matters. With the first idea, by contrary, only already build drivers, i.e, user=20 desired and system supported, are scanned. Also, with the second idea I think that the driver-ids (the magic numbers= ) can=20 go away -- ah, no, for historical reasons the xwin driver must be number = one,=20 the tk driver number 2, etc. hmm, there is another solution for this but = let=20 discuss it latter. If performance is really an issue, then one could implements a mixing of = the=20 two ideas: don't generate drivers.db at configure nor build time. At run = time=20 if drivers.db does not exists, scan the drivers and build it. This way th= e=20 performance loss will only occurs once. If a new driver is latter added to the directory (not probable, but possi= ble,=20 after all this is the only advantage of dyndrivers), one could first comp= are=20 the time-stamp of all drivers versus the drivers.db file, and rebuild=20 drivers.db if a driver is more recent. Reading time-stamp is fast, I beli= eve. Joao |
From: Joao C. <jc...@fe...> - 2003-02-05 02:11:23
|
On Tuesday 04 February 2003 23:11, Alan W. Irwin wrote: > On Tue, 4 Feb 2003, Rafael Laboissiere wrote: =2E.. > > I also noticed that the > > pstex entry was wrongly written in drivers.db. Apparently, this bug = have > > never bothered our users... > > I have forgotten the details, but IIRC, I checked that drivers.db anoma= ly > before, and I am pretty sure it is necessary in order for pstex to work= =2E > Something to do with the way pstex depends on ps or vice versa. > > Joao, do you remember about this? No. I only remember that the pstex configuration changed a couple of time= s. The pstex needs the ps driver, directly calling the ps driver entry point= s. If it works with Rafael changes, that's fine for me. For a quick test use= any=20 C example and the scripts/pstex2eps script to generate an eps. > > Alan |
From: Alan W. I. <ir...@be...> - 2003-02-04 23:12:34
|
On Tue, 4 Feb 2003, Rafael Laboissiere wrote: > 3) When the library is initialized, if dyndrivers are enabled, the drivers > directory is scanned for the *.la files. Each found driver is dlopened > and the DEVICE_INFO_<driver> symbol is read and put in a temporary file. Are you using "dlopen" in the generic sense here? The actual call should be to lt_dlopenext, and you have to be careful of the argument (follow exactly what I did with drvnam and drvspec so the file name comes out exactly the same to get it to work cross-platform). > c) At build time (not configuration time), a small C program dlopen the > <driver>.c files, Same comment. My initial use of lt_dlopenext worked fine on Linux but died horribly on OSF1 until I made my final changes to the lt_dlopenext argument. > Postscript > ========== > > In doing my changes, I noticed that the following drivers have never had > entries in drivers.db: plbuf.c and next.c. Does anyone know why? IIRC next.c is completely unmaintained and kept in CVS only as an encouragment for somebody, someday, to get it going again. plbuf.c is not a driver in the traditional sense. I believe it is in the wrong directory and should be put in src instead. It's code is put directly into the libplplot library (see src/Makefile.am). > I also noticed that the > pstex entry was wrongly written in drivers.db. Apparently, this bug have > never bothered our users... I have forgotten the details, but IIRC, I checked that drivers.db anomaly before, and I am pretty sure it is necessary in order for pstex to work. Something to do with the way pstex depends on ps or vice versa. Joao, do you remember about this? 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-02-04 21:47:12
|
Preamble ======== The big recent cvs commit regarding the dyndrivers database was on the top of my TODO list. It is a necessary step towards clean configuration/building and also packaging for Debian. I am not yet completely happy with my implementation, but my changes (apparently) did not break PLplot. My simple test script succeeded, at least. I am committing without previous discussion here because, as Alan uses to say, getting novelties in cvs HEAD is the best way to foster discussions. The Problem =========== The way PLplot used to get information about the available devices provided by the dyndrivers was through the DATA_DIR/drivers.db file. This file was generated at configuration time and parsed when the library was initialized. This approach has two drawbacks: 1) Information about the devices are scattered in different places (namely in the driver source file and in configure.ac). This is ugly and may result in unnecessary maintenance burden. 2) Since the list of available devices is hardcoded in the drivers.db it is almost impossible to do clean packaging of Plplot. In Debian, for instance, packaging is granular in order to reduce the dependencies: plplot-xwin, plplot-tk, plplot-gd, etc. Users can install a subset of the available packages at will. However, they will always get the full list of available devices when plinit is called. That is not a critical problem, but annoying. The Solution ============ I have elaborated a full fix for this problem, but I just committed an intermediary solution for it. Here is how it works: 1) drivers.db does not exist anymore. 2) In each driver file, there is a global declaration like this: char* DEVICE_INFO_gd = "jpeg:JPEG file:0:gd:40:jpeg\n" "png:PNG file:0:gd:39:png"; containing the entries that used to go into drivers.db. If a driver provides more than one device, their entries must be separated by a newline character ('\n'). 3) When the library is initialized, if dyndrivers are enabled, the drivers directory is scanned for the *.la files. Each found driver is dlopened and the DEVICE_INFO_<driver> symbol is read and put in a temporary file. 4) This temporary file plays the role of the old drivers.db file. Noticed that I did minimal changes to Geoff's code in plcore.c. In the plInitDispatchTable function, I replaced the initial code (where the drivers.db were scanned) by the scanning of the drivers directory described in point 3 above. Also, all references to drivers.db and DRIVERS_DB have disappeared from the sources. Drawbacks and improvements ========================== I see two potential problems with my approach: 1) Portability. I am using new libc functions (POSIX tmpfile, opendir, readdir and closedir). Although am I following the recommended procedure found in the Autoconf docs (i.e. using AC_HEADER_DIRENT and a couple of tests with HAVE_DIRENT_H), I am sure that there will be some weird system out there (MacIntosh, say) for which my code won't compile. If that happens, we have to port that part of the code. 2) With my approach, I have to open all and every module before using them. This may appear as a regression as regards the "cache file" approach provided by the use of drivers.db. In terms of performance, with our current computer power, the overload is negligible. However, as I wrote above, my original design was much better, but harder to implement (of course). It looks like this: a) Forget about that entries a la drivers.db. b) In each driver file <driver>.c define symbols DEV_DESC_*, DEV_SEQ_*, DEV_TAG_*, etc. These symbols can be used when filling fields in function plD_dispatch_init_<device>. This would further reduce the maintenance problem due to duplication of information. c) At build time (not configuration time), a small C program dlopen the <driver>.c files, get the symbols described above and write the associated device entries in <driver>.rc (or whichever name). d) Those <driver>.rc are installed in the drivers directory, along with the <driver>.la and <driver>.so files. e) When PLplot is initialized, the <driver>.rc files are scanned. If I have some time before the 5.2.1 release, I will try to implement this idea. Postscript ========== In doing my changes, I noticed that the following drivers have never had entries in drivers.db: plbuf.c and next.c. Does anyone know why? I introduced the DEVICE_INFO_<driver> symbol in all drivers listed in variable EXTRA_LTLIBRARIES of drivers/Makefile.am. I also noticed that the pstex entry was wrongly written in drivers.db. Apparently, this bug have never bothered our users... -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-02-04 18:18:03
|
On Tue, 4 Feb 2003, Joao Cardoso wrote: > > Maurice, I believe you have had prior experience with AIX. There are > > no math calls in tclMatrix.c and matrixInit.c, but I am wondering if > > (many!) unresolved math symbols in -ltcl8.3 are causing the link problem. Thanks, Maurice, for answering that question separately. > > I think that the source of most problems is the link command used. On a > previous report there were many plplot API entries that were missing, > although the command line specifies -lplplot. Actually, Joao, there has now been one further iteration and Don reports that --disable-cxx --disable-f77 --disable-tcl builds fine on AIX. There is one other installation problem we are sorting out at the moment, but once that is done, I am discussing a possible fix for tcl/tk with Maurice which I hope that Don would be willing to test before 5.2.1. The AIX fixes for f77 and C++ are not so obvious so we may have to put those off until after 5.2.1. 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-02-04 13:11:06
|
On Tuesday 04 February 2003 08:35, Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2003-02-03 14:17]: > > On Mon, 3 Feb 2003, Rafael Laboissiere wrote: > > > > make[3]: Entering directory `/home/jcard/plplot/bindings/python' > > > > python -o plplotcmodule_p_double.c -c++ -DPL_DOUBLE \ > > > > plplotcmodule.i > > > > Unknown option: -o > > > > > > No idea about this. Alan? > > > > The command should be > > > > $(SWIG) -python -o plplotcmodule_p_double.c -c++ -DPL_DOUBLE \ > > plplotcmodule.i > > > > So I think his error message is caused because $(SWIG) is undefined f= or > > him, but I don't know the root cause of that problem. One possibility= is > > the old autotools versions he is using. Another possibility is he may > > have forgot to specify --enable-maintainer-mode for his ./configure > > option. I don't know whether that is essential or not after you have > > done a make > > maintainer-clean, but I suspect it is. > > > > What happens, Joao, for the latest stable autotools versions, clean > > PLplot checkout, and --enable-maintainer-mode? > > Your diagnosis above related to the $(SWIG) variable is correct. Howev= er, > the problem cannot be caused at all by the absence of the option > --enable-maintainer-mode. I introduced maintainer-mode in a recent com= mit > (by adding AM_MAINTAINER_MODE to configure.ac) but for now the only thi= ng > that is done in maintainer mode is the printing of a warning message ab= out > the unavailability of swig. > > To sum up: even with option --disable-maintainer-mode (or, equivalently= , by > omitting --enable-maintainer-mode), but with --enable-python, the swig > checks are done, and the SWIG variable *must* be AC_SUBSTituted by eith= er > "swig" or "echo swig program not available #". > > I think that Joao should, first of all, update his AutoTools to the lat= est > versions, and then try to reproduce the bug. Yes, I will do that, give me some more time :) Joao |
From: Rafael L. <lab...@ps...> - 2003-02-04 09:00:59
|
* Alan W. Irwin <ir...@be...> [2003-02-03 14:17]: > On Mon, 3 Feb 2003, Rafael Laboissiere wrote: > > > > > > make[3]: Entering directory `/home/jcard/plplot/bindings/python' > > > python -o plplotcmodule_p_double.c -c++ -DPL_DOUBLE \ > > > plplotcmodule.i > > > Unknown option: -o > > > > No idea about this. Alan? > > The command should be > > $(SWIG) -python -o plplotcmodule_p_double.c -c++ -DPL_DOUBLE \ > plplotcmodule.i > > So I think his error message is caused because $(SWIG) is undefined for him, > but I don't know the root cause of that problem. One possibility is the old > autotools versions he is using. Another possibility is he may have forgot to > specify --enable-maintainer-mode for his ./configure option. I don't know > whether that is essential or not after you have done a make > maintainer-clean, but I suspect it is. > > What happens, Joao, for the latest stable autotools versions, clean PLplot > checkout, and --enable-maintainer-mode? Your diagnosis above related to the $(SWIG) variable is correct. However, the problem cannot be caused at all by the absence of the option --enable-maintainer-mode. I introduced maintainer-mode in a recent commit (by adding AM_MAINTAINER_MODE to configure.ac) but for now the only thing that is done in maintainer mode is the printing of a warning message about the unavailability of swig. To sum up: even with option --disable-maintainer-mode (or, equivalently, by omitting --enable-maintainer-mode), but with --enable-python, the swig checks are done, and the SWIG variable *must* be AC_SUBSTituted by either "swig" or "echo swig program not available #". I think that Joao should, first of all, update his AutoTools to the latest versions, and then try to reproduce the bug. -- Rafael |
From: Joao C. <jc...@fe...> - 2003-02-04 04:09:51
|
On Tuesday 04 February 2003 03:51, Maurice LeBrun wrote: > Joao Cardoso writes: > > On Monday 03 February 2003 21:36, Rafael Laboissiere wrote: > > > * Rafael Laboissiere <lab...@ps...> [2003-02-03 21:35]: > > > > * Jo=E3o Cardoso <jc...@fe...> [2003-02-03 17:12]: > > > > > 2 - Also, when configure reaches libbltdl it does not uses the > > > > > configure cache, which can make configure faster: > > > > > > > > I will take a look at this. > > > > > > I did. Give option --cache-file=3Dconfig.cache to ./configure. T= his > > > will be inherited by libltdl/configure, and many tests will be cac= hed, > > > with improvements in speed. > > > > Thanks. Couldn't it be done by default? > > I use to see this feature enabled in other packages, although what > > autoconf info says about "`configure' uses no cache file ... to avoi= d > > problems caused by accidental use of stale cache files."? > > I always turned off cache files by default under the old configuration > scheme, because the risk just wasn't worth it.. i.e. I've been burned b= y > it. If you reconfigure plplot using new command line flags the cache f= ile > MUST be invalidated or you will be burned too. If this requirement can= 't > be satisfied it should probably be left off. OK, Joao |
From: Maurice L. <mj...@ga...> - 2003-02-04 03:56:32
|
Alan W. Irwin writes: > On Mon, 3 Feb 2003, Don Spong wrote: > > [...] > > gcc -shared -o .libs/libtclmatrix.so.5 tclMatrix.o matrixInit.o > > -L/usr/local/lib -ltcl8.3 -lc -Wl,-bnoentry > > -Wl,-bexport:.libs/libtclmatrix.exp > > ld: 0711-317 ERROR: Undefined symbol: acos > > ld: 0711-317 ERROR: Undefined symbol: asin > > ld: 0711-317 ERROR: Undefined symbol: atan > > ld: 0711-317 ERROR: Undefined symbol: atan2 > > ld: 0711-317 ERROR: Undefined symbol: ceil > > ld: 0711-317 ERROR: Undefined symbol: cos > > ld: 0711-317 ERROR: Undefined symbol: cosh > > ld: 0711-317 ERROR: Undefined symbol: exp > > ld: 0711-317 ERROR: Undefined symbol: floor > > ld: 0711-317 ERROR: Undefined symbol: fmod > > ld: 0711-317 ERROR: Undefined symbol: hypot > > ld: 0711-317 ERROR: Undefined symbol: log > > ld: 0711-317 ERROR: Undefined symbol: log10 > > ld: 0711-317 ERROR: Undefined symbol: pow > > ld: 0711-317 ERROR: Undefined symbol: sin > > ld: 0711-317 ERROR: Undefined symbol: sinh > > ld: 0711-317 ERROR: Undefined symbol: sqrt > > ld: 0711-317 ERROR: Undefined symbol: tan > > ld: 0711-317 ERROR: Undefined symbol: tanh > > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. > > collect2: ld returned 8 exit status > > make: 1254-004 The error code from the last command is 1. > > Maurice, I believe you have had prior experience with AIX. There are > no math calls in tclMatrix.c and matrixInit.c, but I am wondering if > (many!) unresolved math symbols in -ltcl8.3 are causing the link problem. Uh.. -lm ? Don't forget we have a record of all the flags used in the previous config system down in cf/. So: $ grep lm cf/lib_sh_aix.in $(SHLIB_LIBS) -lc -lm 2>ld.out $(SHLIB_LIBS) -lc -lm 2>ld.out $(SHLIB_LIBS) -lc -lm 2>ld.out -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Maurice L. <mj...@ga...> - 2003-02-04 03:52:22
|
Joao Cardoso writes: > On Monday 03 February 2003 21:36, Rafael Laboissiere wrote: > > * Rafael Laboissiere <lab...@ps...> [2003-02-03 21:35]: > > > * Jo=E3o Cardoso <jc...@fe...> [2003-02-03 17:12]: > > > > 2 - Also, when configure reaches libbltdl it does not uses the= > > > > configure cache, which can make configure faster: > > > > > > I will take a look at this. > > > > I did. Give option --cache-file=3Dconfig.cache to ./configure. T= his will be > > inherited by libltdl/configure, and many tests will be cached, wit= h > > improvements in speed. >=20 > Thanks. Couldn't it be done by default? > I use to see this feature enabled in other packages, although what a= utoconf=20 > info says about "`configure' uses no cache file ... to avoid problem= s caused=20 > by accidental use of stale cache files."? I always turned off cache files by default under the old configuration = scheme, because the risk just wasn't worth it.. i.e. I've been burned by it. I= f you reconfigure plplot using new command line flags the cache file MUST be invalidated or you will be burned too. If this requirement can't be sa= tisfied it should probably be left off. --=20 Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (= RIST) |
From: Joao C. <jc...@fe...> - 2003-02-04 02:54:12
|
On Tuesday 04 February 2003 00:01, Alan W. Irwin wrote: > On Mon, 3 Feb 2003, Don Spong wrote: > > [...] > > > =09/bin/sh ../../libtool --mode=3Dlink gcc -g -O2 -o > > libtclmatrix.la -rpath /home/spongda/plplot-5.2.0/lib -version-info > > 7:0:2 -rpath /home/spongda/plplot-5.2.0/lib -no-undefined > > -L/usr/local/lib -ltcl8.3 tclMatrix.lo matrixInit.lo > > mkdir .libs > > rm -fr .libs/libtclmatrix.la .libs/libtclmatrix.* .libs/libtclmatrix.= * > > (cd . && ln -s tclMatrix.lo tclMatrix.o) > > (cd . && ln -s matrixInit.lo matrixInit.o) > > generating symbol list for `libtclmatrix.la' > > /bin/nm -B tclMatrix.o matrixInit.o | sed -n -e 's/^.*[ > > =09]\([BCDT][BCDT]*\)[=09][ > > =09]*\(\)\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2\3 \3/p' | sed 's/.* > > //' | sort | uniq > .libs/libtclmatrix.exp > > gcc -shared -o .libs/libtclmatrix.so.5 tclMatrix.o matrixInit.o > > -L/usr/local/lib -ltcl8.3 -lc -Wl,-bnoentry > > -Wl,-bexport:.libs/libtclmatrix.exp =2E.. > > ld: 0711-317 ERROR: Undefined symbol: tan > > ld: 0711-317 ERROR: Undefined symbol: tanh > > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more > > information. collect2: ld returned 8 exit status > > make: 1254-004 The error code from the last command is 1. > > Maurice, I believe you have had prior experience with AIX. There are > no math calls in tclMatrix.c and matrixInit.c, but I am wondering if > (many!) unresolved math symbols in -ltcl8.3 are causing the link proble= m. I think that the source of most problems is the link command used. On a=20 previous report there were many plplot API entries that were missing,=20 although the command line specifies -lplplot. Perhaps Don's AIX isn't fully supported by libtool? Although libtool *say= s*=20 during configure that it *knows* how to build shared libs in the detected= =20 system! checking build system type... powerpc-ibm-aix4.3.3.0 ... checking whether the linker (/bin/ld) supports shared libraries... yes ... checking if libtool supports shared libraries... yes =20 I'm afraid that without a AIX system it will be difficult for us to trace= and=20 fix the problem. > > This may be related to our convoluted method of determining the tcl lin= k > line in sysloc.in. Perhaps better cross-platform support would be > automatic if we use what Rafael was recommending > (/usr/share/aclocal/tcl.m4) as a replacement? > > Meanwhile, Don, to move by this, I suggest you disable our tcl front-en= d. > (--disable-tcl). Yes,=20 1-Disable *everything*,=20 --disable-tcl --disable-tk --disable-itcl --disable-cxx --disable-f77 =20 --enable-dyndrivers --disable-static --enable-shared. Only the C library will be build with shared libs and dynamic drivers. Do= n't=20 forget to follow Alan's recomendations and unpack the sources fresh each = time=20 -- or at least do a "make clean". 2-If the above don't work, the next step will be giving up of shared libs= and=20 build only static libs: --disable-tcl --disable-tk --disable-itcl --disable-cxx --disable-f77=20 --disable-shared 3-Don, you might need the fortran bindings, but if you can't compile the = basic=20 C library there is no hope for you (for now, please be patient and wait f= or=20 5.2.1) Joao |