Menu
▾
▴
gnuplot-beta
|
From: <br...@ph...> - 2006-10-01 15:33:43
|
Hello, everybody, this 4.2 release process is taking a little longer than expected. So, based on a suggestion from Ethan, I've decided to start what the German proverb calls "making nails with heads". CVS is branched (branch tag branch-4-2-stable), VERSION is 4.2 and PATCHLEVEL is rc1 (for now on both the head and the 4.2 branch). Everybody should check out a working copy of the branch, and test that it works as expected, on as many platforms as you can. I'll also put up a release candidate source tarball on SF.net (in the "gnuplot-current" subproject of the file release system). I think this candidate should be considered "beta", i.e. no publication of binary packages just yet, please. |
|
From: <tim...@en...> - 2006-10-01 16:34:06
Attachments:
configurefix.diff
|
Hans-Bernhard Br=F6ker wrote: > Hello, everybody, > > this 4.2 release process is taking a little longer than expected. So,=20 > based on a suggestion from Ethan, I've decided to start what the German= =20 > proverb calls "making nails with heads". CVS is branched (branch tag=20 > branch-4-2-stable), VERSION is 4.2 and PATCHLEVEL is rc1 (for now on=20 > both the head and the 4.2 branch). > > Everybody should check out a working copy of the branch, and test that=20 > it works as expected, on as many platforms as you can. > > I'll also put up a release candidate source tarball on SF.net (in the=20 > "gnuplot-current" subproject of the file release system). > > I think this candidate should be considered "beta", i.e. no publication= =20 > of binary packages just yet, please. > =20 Great ! I already have a little patch to offer for a bug in the configure script. The patch first fixes the build of gnuplot when libpdf and gd are not=20 installed in standard directories. In those situations, whereas=20 configure was checking for the position of the gdlib-config and=20 pdflib-config scripts, it did not use the result ! Moreover, there is a problem with gd on systems where GNU libiconv is=20 installed. In this case, gnuplot has to be linked against libiconv too,=20 or undefined references are obtained. The first offender here is=20 gdlib-config itself which doesn't report correctly '-liconv' but a full=20 path to libiconv.so. But even if gd gets fixed in a future release (I=20 will send the corresponding patch to M. Boutell soon), the configure=20 script would not catch it since it doesn't take 'gdlib-config --libs'=20 into account. The attached patch fixes this issue too. With both gnuplot and gd fixed, the following are fixed :=20 http://groups.google.com.hk/group/comp.graphics.apps.gnuplot/browse_threa= d/thread/251b6f34c427ac49/9d88d080509b83f3#9d88d080509b83f3 and probably : http://groups.google.com.hk/group/comp.graphics.apps.gnuplot/browse_frm/t= hread/d508bd940d3a4b6e/15014a2704cf040b?lnk=3Dgst&q=3D%22libiconv_close%2= 2&rnum=3D1#15014a2704cf040b Without gd fixed, LIBS=3D'-liconv' had to be used when calling 'configure= '. May I push this bugfix patch to the 4.2 branch, or do you consider this=20 for post-4.2 ? Best regards, Timoth=E9e |
|
From: <br...@ph...> - 2006-10-01 17:27:06
|
Timoth=E9e Lecomte wrote: > The patch first fixes the build of gnuplot when libpdf and gd are n= ot=20 > installed in standard directories. In those situations, whereas= =20 > configure was checking for the position of the gdlib-config and= =20 > pdflib-config scripts, it did not use the result ! I don't think your analysis of this is correct. GDLIB_CONFIG is=20 searched in the same $PATH the shell will search it in. So if=20 AC_CHECK_PROG found it, so will the shell if you run by just "gdlib-c= onfig". > Moreover, there is a problem with gd on systems where GNU libiconv = is=20 > installed. In this case, gnuplot has to be linked against libiconv = too,=20 > or undefined references are obtained. The first offender here is= =20 > gdlib-config itself which doesn't report correctly '-liconv' but a = full=20 > path to libiconv.so.=20 I don't think that's actually wrong. Iconv is a massively overloaded= =20 name for a library --- it may well be one library that you *don't* wa= nt=20 to trust the -l option to find the right copy of. > script would not catch it since it doesn't take 'gdlib-config --lib= s'=20 > into account. The attached patch fixes this issue too. I've learned to mistrust any obvious or easy changes to the GD=20 configury. Before you added wx (and all the other libs it depends on= ),=20 GD was easily the single most tricky external library we ever linked= =20 against. E.g. on some platforms, one *must* link with all the=20 underlying libraries explicitly, on others, it's basically forbidden = to=20 try --- depending on exotica like whether a platform's shared librari= es=20 dynamically link to other shared libraries. > Without gd fixed, LIBS=3D'-liconv' had to be used when calling 'con= figure'. This looks wrong. This can only really fail if libiconv was moved awa= y=20 since its position was hard-coded into gdlib-config. In that case, t= he=20 GD installation has to be considered FUBAR. It has to be reinstalled= . |
|
From: <tim...@en...> - 2006-10-01 22:55:05
|
Hans-Bernhard Br=F6ker wrote:
> Timoth=E9e Lecomte wrote:
>
>> The patch first fixes the build of gnuplot when libpdf and gd are not=20
>> installed in standard directories. In those situations, whereas=20
>> configure was checking for the position of the gdlib-config and=20
>> pdflib-config scripts, it did not use the result !
>
> I don't think your analysis of this is correct. GDLIB_CONFIG is=20
> searched in the same $PATH the shell will search it in. So if=20
> AC_CHECK_PROG found it, so will the shell if you run by just=20
> "gdlib-config".
Hmm... You seem to be right. In fact, the important detail here is that=20
the user I've been discussing with has set the environment variable=20
GDLIB_CONFIG to his gdlib-config script before running 'configure'. I=20
don't really know where he found the idea to do it, but there is=20
definitely the autoconf magic to do it. It's mentioned in the help page=20
of AC_PATH_PROG, and it's called a "precious variable", as a variable=20
that can also be set by the environment, not only by a test. Maybe we=20
should declare it with AC_ARG_VAR to remove all possible ambiguity.
>
>> Moreover, there is a problem with gd on systems where GNU libiconv is=20
>> installed. In this case, gnuplot has to be linked against libiconv=20
>> too, or undefined references are obtained. The first offender here is=20
>> gdlib-config itself which doesn't report correctly '-liconv' but a=20
>> full path to libiconv.so.=20
>
> I don't think that's actually wrong. Iconv is a massively overloaded=20
> name for a library --- it may well be one library that you *don't*=20
> want to trust the -l option to find the right copy of.
I'm not disputing the fact that there may be multiple copies, I'm=20
disputing the fact that gdlib-config reports the following, when linked=20
to GNU libiconv:
/home/research/csmkchan/lib/libiconv.so=20
-Wl,-rpath,/home/research/csmkchan/lib/
whereas I think it should report:
-L/home/research/csmkchan/lib -liconv -R/home/research/csmkchan/lib
(for details, gd uses LIBICONV instead of LTLIBICONV in its configure=20
script, see=20
http://www.gnu.org/software/gettext/manual/html_node/gettext_189.html
that's probably wrong since gd is precisely built as a libtool library).
>
>> script would not catch it since it doesn't take 'gdlib-config --libs'=20
>> into account. The attached patch fixes this issue too.
>
> I've learned to mistrust any obvious or easy changes to the GD=20
> configury. Before you added wx (and all the other libs it depends=20
> on), GD was easily the single most tricky external library we ever=20
> linked against. E.g. on some platforms, one *must* link with all the=20
> underlying libraries explicitly, on others, it's basically forbidden=20
> to try --- depending on exotica like whether a platform's shared=20
> libraries dynamically link to other shared libraries.
I agree there may be some strange things going on there...
But look carefully at the patch: as it was written before, the contents=20
of 'gdlib-config --libs' was added to TERMLIBS after the checks, so=20
gnuplot was effectively linked against all those libs. _But_ it was=20
added _after_ the checks for gdImageCreate and friends. _This_ is the=20
bug. On IRC, I checked the config.log files of "Michael" who just posted=20
to comp.graphics.apps.gnuplot under the thread "Installing 4.1", and he=20
precisely got caught by this: 'gdlib-config --libs' was asking to link=20
against libiconv, but as this wasn't added for gnuplot checks, he=20
eventually ended up with gd not found and the errors mentioned in the=20
thread.
Best regards,
Timoth=E9e Lecomte
|
|
From: <br...@ph...> - 2006-10-02 18:54:00
|
Timoth=E9e Lecomte wrote: > Hans-Bernhard Br=F6ker wrote: >> Timoth=E9e Lecomte wrote: >>> The patch first fixes the build of gnuplot when libpdf and gd are= not=20 >>> installed in standard directories. In those situations, whereas= =20 >>> configure was checking for the position of the gdlib-config and= =20 >>> pdflib-config scripts, it did not use the result ! > Hmm... You seem to be right. In fact, the important detail here is = that=20 > the user I've been discussing with has set the environment variable= =20 > GDLIB_CONFIG to his gdlib-config script before running 'configure'.= =20 Wrong approach, IMHO. If gdlib-config isn't in the PATH, that in its= elf=20 implies a broken GD installation, or someone trying to use a GD that= =20 hasn't been installed yet. > I don't really know where he found the idea to do it, but there is > definitely the autoconf magic to do it. It's mentioned in the help = page=20 > of AC_PATH_PROG, and it's called a "precious variable",=20 Not really. The doc only "strongly suggests" that we should make it = a=20 precious variable, not that autoconf doest that by itself --- and we= =20 don't do that. > I'm not disputing the fact that there may be multiple copies, I'm= =20 > disputing the fact that gdlib-config reports the following, when li= nked=20 > to GNU libiconv: >=20 > /home/research/csmkchan/lib/libiconv.so=20 > -Wl,-rpath,/home/research/csmkchan/lib/ >=20 > whereas I think it should report: >=20 > -L/home/research/csmkchan/lib -liconv -R/home/research/csmkchan/= lib And I have a feeling that Mr. Boutell (or GNU gettext/iconv=20 autoconfigury) did this on purpose, for a very good reason. The prob= lem=20 with iconv is that terribly often, there will be two libraries under= =20 this name on non-GNU Unix box: GNU's version, and the vendor's. And= =20 it's very important that you get exactly the one you want. Using the= =20 -L/-l search mechanism would be fatal in that case. Anyway: specifying the library name full can't cause any problem. It= 's=20 not a bug. > But look carefully at the patch: as it was written before, the cont= ents=20 > of 'gdlib-config --libs' was added to TERMLIBS after the checks, so= =20 > gnuplot was effectively linked against all those libs.=20 I'm aware of that part, and also that changing it would fix the OP's= =20 problem. The nasty question is: what will that change do to *other*= =20 people's configurations? |
|
From: <tim...@en...> - 2006-10-02 21:27:02
|
Hans-Bernhard Br=F6ker wrote: > Timoth=E9e Lecomte wrote: >> Hans-Bernhard Br=F6ker wrote: >>> Timoth=E9e Lecomte wrote: > >>>> The patch first fixes the build of gnuplot when libpdf and gd are=20 >>>> not installed in standard directories. In those situations, whereas=20 >>>> configure was checking for the position of the gdlib-config and=20 >>>> pdflib-config scripts, it did not use the result ! > >> Hmm... You seem to be right. In fact, the important detail here is=20 >> that the user I've been discussing with has set the environment=20 >> variable GDLIB_CONFIG to his gdlib-config script before running=20 >> 'configure'.=20 > > Wrong approach, IMHO. If gdlib-config isn't in the PATH, that in=20 > itself implies a broken GD installation, or someone trying to use a GD=20 > that hasn't been installed yet. I assume that some install in their home directory and don't have the=20 reflex to change the path... The user I told to was obviously using a=20 machine maintained by his university, so he had to install in his home=20 directory. The idea to do it through GDLIB_CONFIG may be a little simpler than=20 changing the path from a developer point of view when you have several=20 installations of a given library (here gd) in different folders. (I tried to declare GDLIB_CONFIG and PDFLIB_CONFIG as precious variables=20 and I think the result is quite good : they appear in ./configure=20 --help, so the situation becomes documented) That is not release-critical, but it would be nice to fix. > > > I don't really know where he found the idea to do it, but there is >> definitely the autoconf magic to do it. It's mentioned in the help=20 >> page of AC_PATH_PROG, and it's called a "precious variable",=20 > > Not really. The doc only "strongly suggests" that we should make it a=20 > precious variable, not that autoconf doest that by itself --- and we=20 > don't do that. > >> I'm not disputing the fact that there may be multiple copies, I'm=20 >> disputing the fact that gdlib-config reports the following, when=20 >> linked to GNU libiconv: >> >> /home/research/csmkchan/lib/libiconv.so=20 >> -Wl,-rpath,/home/research/csmkchan/lib/ >> >> whereas I think it should report: >> >> -L/home/research/csmkchan/lib -liconv -R/home/research/csmkchan/lib > > And I have a feeling that Mr. Boutell (or GNU gettext/iconv=20 > autoconfigury) did this on purpose, for a very good reason. The=20 > problem with iconv is that terribly often, there will be two libraries=20 > under this name on non-GNU Unix box: GNU's version, and the vendor's. =20 > And it's very important that you get exactly the one you want. Using=20 > the -L/-l search mechanism would be fatal in that case. > > Anyway: specifying the library name full can't cause any problem. =20 > It's not a bug. You convinced me. I guess I was mislead (again !) by my google searchs=20 on this problem, where I read that people had to set "LIBS=3D-liconv" by=20 hand. It's obviously a workaround but did hide the real problem. > >> But look carefully at the patch: as it was written before, the=20 >> contents of 'gdlib-config --libs' was added to TERMLIBS after the=20 >> checks, so gnuplot was effectively linked against all those libs.=20 > > I'm aware of that part, and also that changing it would fix the OP's=20 > problem. The nasty question is: what will that change do to *other*=20 > people's configurations? > I can't see a situation where taking 'gdlib-config --libs' into account=20 would change anything. Do you have an example ? Timoth=E9e |
|
From: <tim...@en...> - 2006-10-02 21:52:46
|
Timoth=E9e Lecomte wrote:
>
> (I tried to declare GDLIB_CONFIG and PDFLIB_CONFIG as precious variable=
s=20
> and I think the result is quite good : they appear in ./configure=20
> --help, so the situation becomes documented)
> =20
Here is the corresponding patch, which does the thing for GDLIB_CONFIG,=20
PDFLIB_CONFIG and WX_CONFIG (I had a small piece of code to handle it=20
with --with-wx-config=3DDIR which becomes useless).
./configure --help gives:
...
GDLIB_CONFIG
Define to the full path of your gdlib-config script
PDFLIB_CONFIG
Define to the full path of your pdflib-config script
PKG_CONFIG path to pkg-config utility
...
WX_CONFIG Define to the full path of your wx-config script
...
Tell me if you eventually think it's ok, or if you don't.
Best regards,
Timoth=E9e
|
|
From: <tim...@en...> - 2006-10-02 21:54:49
Attachments:
configurefix.diff
|
Timoth=E9e Lecomte wrote: > Timoth=E9e Lecomte wrote: > =20 >> (I tried to declare GDLIB_CONFIG and PDFLIB_CONFIG as precious variabl= es=20 >> and I think the result is quite good : they appear in ./configure=20 >> --help, so the situation becomes documented) >> =20 >> =20 > > Here is the corresponding patch (...) Here it is, actually. Sorry for the noise. |
|
From: Lars H. <lhe...@us...> - 2006-10-06 23:31:37
|
Timoth?e Lecomte writes: [...] > I'm not disputing the fact that there may be multiple copies, I'm > disputing the fact that gdlib-config reports the following, when linked > to GNU libiconv: > > /home/research/csmkchan/lib/libiconv.so > -Wl,-rpath,/home/research/csmkchan/lib/ This looks wrong. Is it really on two lines? If the .so can be linked explicitly, and I'm not even sure this can be done, the rpath directive is surely not needed. > whereas I think it should report: > > -L/home/research/csmkchan/lib -liconv -R/home/research/csmkchan/lib > > (for details, gd uses LIBICONV instead of LTLIBICONV in its configure > script, see > http://www.gnu.org/software/gettext/manual/html_node/gettext_189.html > that's probably wrong since gd is precisely built as a libtool library). I will check this out and fix it if necessary. > But look carefully at the patch: as it was written before, the contents > of 'gdlib-config --libs' was added to TERMLIBS after the checks, so > gnuplot was effectively linked against all those libs. _But_ it was > added _after_ the checks for gdImageCreate and friends. _This_ is the > bug. This seems logically correct to me: the libs are added after the (successful) check. > On IRC, I checked the config.log files of "Michael" who just posted > to comp.graphics.apps.gnuplot under the thread "Installing 4.1", and he > precisely got caught by this: 'gdlib-config --libs' was asking to link > against libiconv, but as this wasn't added for gnuplot checks, he > eventually ended up with gd not found and the errors mentioned in the > thread. I'll see if I can find this. Gnuplot's configure uses the library's config script precisely to keep complexity down so that it doesn't need to cover indirect library dependencies. |
|
From: Lars H. <lhe...@us...> - 2006-10-09 17:23:43
|
My mails still haven't appeared on the list ... Timoth?e Lecomte writes: [...] > Moreover, there is a problem with gd on systems where GNU libiconv is > installed. In this case, gnuplot has to be linked against libiconv too, > or undefined references are obtained. The first offender here is > gdlib-config itself which doesn't report correctly '-liconv' but a full > path to libiconv.so. But even if gd gets fixed in a future release (I > will send the corresponding patch to M. Boutell soon), the configure > script would not catch it since it doesn't take 'gdlib-config --libs' > into account. The attached patch fixes this issue too. I now understand this problem. Linking with gd also requires iconv in some cases, but gdlib-config provides iconv in --libs, which we only use after configure comes back positive for gd - chicken and egg. The only solution I can offer is to do no configure checks for gd at all if gdlib-config is found. Potentially for pdflib, too. |
|
From: <tim...@en...> - 2006-10-09 19:53:32
Attachments:
configurefix.diff
|
Lars Hecking wrote: > My mails still haven't appeared on the list ... > > Timoth?e Lecomte writes: > [...]=20 > =20 >> Moreover, there is a problem with gd on systems where GNU libiconv is=20 >> installed. In this case, gnuplot has to be linked against libiconv too= ,=20 >> or undefined references are obtained. The first offender here is=20 >> gdlib-config itself which doesn't report correctly '-liconv' but a ful= l=20 >> path to libiconv.so. But even if gd gets fixed in a future release (I=20 >> will send the corresponding patch to M. Boutell soon), the configure=20 >> script would not catch it since it doesn't take 'gdlib-config --libs'=20 >> into account. The attached patch fixes this issue too. >> =20 > > I now understand this problem. Linking with gd also requires iconv in > some cases, but gdlib-config provides iconv in --libs, which we only > use after configure comes back positive for gd - chicken and egg. > > The only solution I can offer is to do no configure checks for gd at a= ll > if gdlib-config is found. Potentially for pdflib, too. > =20 What about the attached solution (posted a few days ago) ? (ignore if you want the changes for AC_ARG_VAR and $GDLIB_CONFIG,=20 although they are useful too) Best regards, Timoth=E9e |
|
From: Petr M. <mi...@ph...> - 2006-10-01 17:30:32
|
> this 4.2 release process is taking a little longer than expected. So, > based on a suggestion from Ethan, I've decided to start what the German > proverb calls "making nails with heads". CVS is branched (branch tag > branch-4-2-stable), VERSION is 4.2 and PATCHLEVEL is rc1 (for now on > both the head and the 4.2 branch). > > Everybody should check out a working copy of the branch, and test that > it works as expected, on as many platforms as you can. Good, just the following three things should go to 4.2 as well (IMHO): - the Rework of configure summary patch - the Wildcard patch and yet another bug report I've found this weekend and passed to Ethan. What about the Gamma problem? Is Mac hurt by it or not? > I'll also put up a release candidate source tarball on SF.net (in the > "gnuplot-current" subproject of the file release system). Please wait for those fixes, and: Some other small tasks to do: - Some (c)/Copyright should be extended to 2006. - Please "everybody" read the TODO file and remove all what's already in. -- There is a long Windows section. -- There is a long Lars' list. - Could the maintainer (Clark?) organize synchronization of http://www.gnuplot.info/development/binaries/ with http://gnuplot.sourceforge.net/development/binaries/ - In README.1ST, I think that sections Note 1 - UNISYS patent (why no more GIF images) Note 2 - Open source programs for PNG to GIF conversion can be completely removed. --- PM |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-10-01 21:45:51
|
On Sunday 01 October 2006 08:35 am, Hans-Bernhard Br=F6ker wrote: >=20 > I'll also put up a release candidate source tarball on SF.net (in the=20 > "gnuplot-current" subproject of the file release system). Great! Please join me in toasting this milestone. Your choice of beer or champagne. I have copied the same tarball to=20 http://gnuplot.sourceforge.net/development/binaries/ since several places in the documentation and web site direct people to that URL. I have started to update the web pages on SourceForge as well. Are the mirror sites automatic, or does someone have to copy stuff over manually? =20 =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Joe K. <jko...@co...> - 2006-10-01 23:04:40
|
on 10/1/06 3:45 PM, Ethan A Merritt at merritt@u.washington.edu wrote: > On Sunday 01 October 2006 08:35 am, Hans-Bernhard Br=F6ker wrote: >>=20 >> I'll also put up a release candidate source tarball on SF.net (in the >> "gnuplot-current" subproject of the file release system). >=20 > Great! > Please join me in toasting this milestone. Your choice of beer or champag= ne. >=20 > I have copied the same tarball to > http://gnuplot.sourceforge.net/development/binaries/ > since several places in the documentation and web site direct people > to that URL. >=20 > I have started to update the web pages on SourceForge as well. > Are the mirror sites automatic, or does someone have to copy stuff > over manually? > =20 > --=20 > Ethan A Merritt > Biomolecular Structure Center > University of Washington, Seattle 98195-7742 Congratulations all around. My Mac G5 build of gnuplot-4.2 seems to be working properly, with only a couple of minor problems (more below). This i= s for OS X 10.4.8 with the Xcode-2.4 developer tools. None of the problems reported with the gamma function for the Intel Macs surfaced on my G5 during the build. The configure script found gamma, lgamm= a and signgam without problems. Both gamma and lgamma plot correctly in gnuplot-4.2. The only problems are apparently related to the documentation via LaTeX, because my installation of gnuplot-4.2 seems to be working correctly. The final part of "make install" is as follows <snip> test -z "/Tools/gnuplot-4.2/usr/local/man/man1" || /bin/sh ../mkinstalldirs "/Tools/gnuplot-4.2/usr/local/man/man1" mkdir /Tools/gnuplot-4.2/usr/local/man mkdir /Tools/gnuplot-4.2/usr/local/man/man1 /usr/bin/install -c -m 644 './gnuplot.1' '/Tools/gnuplot-4.2/usr/local/man/man1/gnuplot.1' make install-data-hook make[3]: Nothing to be done for `install-data-hook'. Making install in demo make[2]: Nothing to be done for `install-exec-am'. make[2]: Nothing to be done for `install-data-am'. Making install in tutorial make[2]: Nothing to be done for `install-exec-am'. make[2]: Nothing to be done for `install-data-am'. Making install in share Making install in LaTeX make[3]: Nothing to be done for `install-exec-am'. make install-data-hook /bin/sh: line 1: kpsexpand: command not found /bin/sh: line 1: texhash: command not found make[4]: *** [install-cfg] Error 127 make[3]: *** [install-data-am] Error 2 make[2]: *** [install-am] Error 2 make[1]: *** [install-recursive] Error 1 make: *** [install-recursive] Error 1 Joe-Koskis-Computer:/Tools/gnuplot-4.2.rc1 jakoski$ But as I said, the installation seems to be working. Simply bypassing the LaTex stuff on Macs would be the easy fix. I think octave already does that= . Joe |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-10-01 23:14:08
|
On Sunday 01 October 2006 04:04 pm, Joe Koski wrote: > The only problems are apparently related to the documentation via LaTeX, > because my installation of gnuplot-4.2 seems to be working correctly. > > The final part of "make install" is as follows > > <snip> > Making install in LaTeX > make[3]: Nothing to be done for `install-exec-am'. > make install-data-hook > /bin/sh: line 1: kpsexpand: command not found > /bin/sh: line 1: texhash: command not found Are you saying that you have kpsexand and texhash installed, but the build process isn't finding it? Or are you saying that since TeX isn't installed on your system, the build process should not bother to recurse into the LaTeX subdirectory? -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Petr M. <mi...@ph...> - 2006-10-02 06:33:50
|
> I have copied the same tarball to > http://gnuplot.sourceforge.net/development/binaries/ > since several places in the documentation and web site direct people > to that URL. > > I have started to update the web pages on SourceForge as well. > Are the mirror sites automatic, or does someone have to copy stuff > over manually? Web page is mirrored automatically, except for the directory http://gnuplot.sourceforge.net/development/binaries/ Discussed several times, but still not fixed -- Clark? Lars? Who can let it working? --- PM |
|
From: <br...@ph...> - 2006-10-02 02:01:16
|
Petr Mikulik wrote: > Good, just the following three things should go to 4.2 as well (IMHO): ... well, then you should make your changes to the branch, too. > - the Wildcard patch I'm not so sure about this. This is a *very* last-minute addition, which has received basically no testing whatsoever. Ethan doesn't consider it release-critical --- I'll leave the eventual decision to him. > What about the Gamma problem? Is Mac hurt by it or not? They're obviously hurt --- the question is what is the best solution we can offer, and whether Apple will ever fix their end of the problem. |
|
From: Daniel J S. <dan...@ie...> - 2006-10-02 02:22:19
|
Hans-Bernhard Br=F6ker wrote: >>What about the Gamma problem? Is Mac hurt by it or not? >=20 >=20 > They're obviously hurt --- the question is what is the best solution we= =20 > can offer, and whether Apple will ever fix their end of the problem. How can we ask someone implementing C99 to manipulate a variable "signgam= " when the C99 standard doesn't call out such a variable? My understandi= ng is that C99 uses tgamma() and lgamma() and there is no need for signga= m. The patch I offered handles this situation. Priority goes to tgamma() an= d lgamma() for the GAMMA() and LNGAMMA() use in specfun.c. If they are n= ot present then it falls back on lgamma_r() and gamma() (ln version) for = GAMMA() and LNGAMMA() use in specfun.c. If those aren't present, gnuplot= falls back on its own version of the routines. The patch never uses sig= ngam because this is not thread safe. It's a very good patch, I believe. Dan |
|
From: Petr M. <mi...@ph...> - 2006-10-02 16:18:37
|
>> Good, just the following three things should go to 4.2 as well (IMHO): >>- Please "everybody" read the TODO file and remove all what's already in. >> -- There is a long Windows section. >> -- There is a long Lars' list. >> - In README.1ST, I think that sections > ... well, then you should make your changes to the branch, too. Yes, I edited these files before posting this message. >> * molecule.dem >> * mouselab_1.dem, mouselab_2.dem, mouselabels.dem, mousevariables.dem >> (move to a subdirectory "mouse"?) I think they should stay all in one directory. --- PM |
|
From: <br...@ph...> - 2006-10-03 07:00:45
|
Petr Mikulik wrote: > Web page is mirrored automatically, except for the directory > http://gnuplot.sourceforge.net/development/binaries/ > Discussed several times, but still not fixed -- Clark? Lars? Who can let it > working? gnuplot.info is Clark's domain, both literally and organizationally. |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-10-06 23:05:42
|
On Sunday 01 October 2006 08:35 am, Hans-Bernhard Br=F6ker wrote: > > Everybody should check out a working copy of the branch, and test > that it works as expected, on as many platforms as you can. AIX 5L Version 5.2 (gcc) - Builds and passes "make check" with no problem (X11 output) =20 Digital Unix 4.0D (DECC compiler) - Builds OK, but ... - triggers floating exception in surface1.dem (Bug #1572268) - triggers floating exception in image.dem when trying to read deliberately wrong-endian binary data (maybe we should remove this demo) Irix 6.5 (MIPSpro Compiler) - Builds and passes "make check" with no problem (PostScript output) =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-10-06 23:56:03
|
On Friday 06 October 2006 04:05 pm, Ethan Merritt wrote: > On Sunday 01 October 2006 08:35 am, Hans-Bernhard Br=F6ker wrote: > > Everybody should check out a working copy of the branch, and test > > that it works as expected, on as many platforms as you can. > > Digital Unix 4.0D (DECC compiler) > - Builds OK, but ... > - triggers floating exception in surface1.dem > (Bug #1572268) > - triggers floating exception in image.dem when trying to > read deliberately wrong-endian binary data > (maybe we should remove this demo) Both of these can be cured by adding "-ieee" to the compiler flags. =20 What is the correct way to have ./configure figure this out? =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Daniel J S. <dan...@ie...> - 2006-10-07 00:01:41
|
Ethan Merritt wrote: > On Friday 06 October 2006 04:05 pm, Ethan Merritt wrote: >=20 >>On Sunday 01 October 2006 08:35 am, Hans-Bernhard Br=F6ker wrote: >> >>>Everybody should check out a working copy of the branch, and test >>>that it works as expected, on as many platforms as you can. >> >>Digital Unix 4.0D (DECC compiler) >> - Builds OK, but ... >> - triggers floating exception in surface1.dem >> (Bug #1572268) >> - triggers floating exception in image.dem when trying to >> read deliberately wrong-endian binary data >> (maybe we should remove this demo) >=20 >=20 > Both of these can be cured by adding "-ieee" to the compiler flags. Interesting. It probably adds a special handler or limits the exceptions= to just those 5 IEEE apparently defines: http://www.unet.univie.ac.at/aix/aixprggd/genprogc/floating-point_except.= htm > What is the correct way to have ./configure figure this out? DEC bought Apollo at some point. Is this compilation one with "APOLLO" d= efined? Then maybe look for APOLLO in configure.in and at that point add= the -ieee to the flags. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-10-06 23:26:35
|
Ethan Merritt wrote: > AIX 5L Version 5.2 (gcc) > - Builds and passes "make check" with no problem (X11 output) > > Digital Unix 4.0D (DECC compiler) > - Builds OK, but ... > - triggers floating exception in surface1.dem > (Bug #1572268) > - triggers floating exception in image.dem when trying to > read deliberately wrong-endian binary data > (maybe we should remove this demo) Well, we could also write a signal handling subroutine. (There is some signal handling stuff in eval.c.) What happens on the DEC with set samples 101 plot 1/x ? Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-10-06 23:36:17
|
On Friday 06 October 2006 04:36 pm, Daniel J Sebald wrote: > Ethan Merritt wrote: > > > > Digital Unix 4.0D (DECC compiler) > > - Builds OK, but ... > > - triggers floating exception in surface1.dem > > (Bug #1572268) > > - triggers floating exception in image.dem when trying to > > read deliberately wrong-endian binary data > > (maybe we should remove this demo) > > What happens on the DEC with > > set samples 101 > plot 1/x Nothing special. The issue is not divide-by-zero or underflow. The wrong-endian exception is from trying to do anything at all with a bit pattern that is not a valid floating point number. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
