gnuplot-beta — Developers and beta testers of new gnuplot code

Re: gnuplot-4.2.rc1: --program-suffix and gnuplot_x11

[Reiner S. <rei...@im...>]

On Wed, Oct 04 2006, Daniel J Sebald wrote:

> Reiner Steib wrote:
>
>> Thanks, the fix works for me.  Unless there's a more clean solution,
>> I'd suggest to install Dan's patch.  The patch doesn't apply anymore
>> to src/Makefile; attached you'll find an updated patch against rc1.
>
> Thank you Reiner.  I've attached the patch you created to the S.F. entry.

Thanks.  The patch works for me WRT the installed binaries.  Now I
tried "make check" with the patch and it failed to locate the
gnuplot_x11 binary:

,----
| make[2]: Entering directory `[...]/gnuplot-4.2.rc1_x11_patch/demo'
| Expected X11 driver: [...]/gnuplot-4.2.rc1_x11_patch/demo/../src/gnuplot_x11-4-2-rc1-x86_64
| Exec failed: No such file or directory
| See 'help x11' for more details
| make[2]: *** [check-noninteractive] Error 141
`----

`src/gnuplot_x11' exist, but `src/gnuplot_x11-4-2-rc1-x86_64' doesn't.

Here are the commands, starting from a fresh rc1:

--8<---------------cut here---------------start------------->8---
patch -p1 < ../prefixsuffix-djs-rsteib-2006-10-04.patch
conf_1="--enable-history-file --with-readline=gnu --enable-mouse"
suffix="4-2-rc1-`uname -m`"
./configure --program-suffix=-"$suffix" --prefix=${SOFT:-/usr/local} $conf_1
rm src/*.o
HOME=. make
make install
make check
--8<---------------cut here---------------end--------------->8---

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Do we need a -no-init-file option?

[Reiner S. <rei...@im...>]

On Thu, Oct 05 2006, Petr Mikulik wrote:

>> We have no such option, but it is an interesting point.
>>
>> 2) setenv GNUPLOTRC "" ; gnuplot
>
> Isn't sufficient:
>  	setenv HOME "."
> ?

For ./tutorial, it would be sufficient, I think.  For the general case
it wont be a good work around.  E.g. you won't be able to use the x11
driver because of ~/.Xauthority.  As a consequence, "HOME=. make
check" fails.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Do we need a -no-init-file option? [was Re: gnuplot-4.2.rc1: tutorial]

[Petr M. <mi...@ph...>]

>> I found the culprit: it's "set encoding iso_8859_1" in `~/.gnuplot'.
>> Does gnuplot have a "-no-init-file" option?
>> Such an option should be used when generating tutorial/eg*.tex.
>
> We have no such option, but it is an interesting point.
>
> 2) setenv GNUPLOTRC "" ; gnuplot

Isn't sufficient:
 	setenv HOME "."
?

---
PM

[4.2-rc1] set term X

[Lutz M. <ma...@be...>]

Hello,

I just tried some of my gnuplot scripts with the 4.2-rc1 version. It turns out 
that a lot of them fail, since I frequently use 'set term X' as an 
abbreviation for 'set term X11'. This does not seem to work with the latest 
version, I get the error message 

  unknown or ambiguous terminal type; type just 'set terminal' for a list

"set terminal" lists x11 and xlib as terminal types starting with 'x'. Up to 
version 4.0 it seems like the terminal name was case sensitive, and 
"X11" (with the abbreviation "X") was explicitly listed to be equivalent to 
"x11".

Would it be possible to reintroduce "X" as a valid abbreviation of "x11", or 
was this decision made on purpose to clean up the code?

  Lutz

Re: Do we need a -no-init-file option?

[Reiner S. <rei...@im...>]

On Wed, Oct 04 2006, Ethan Merritt wrote:

> 1) gnuplot -no-init-file 
>    If the command line option is present,
>    skip the call to load_rcfile()  on line 563 of plot.c
>
> 2) setenv GNUPLOTRC "" ; gnuplot 
>    The init file name is hard-coded into the string constant PLOTRC.
>    We could provide an environment variable that overrides this.
>    Setting it to "" or to any non-existent file name would 
>    bypass the default names "~/.gnuplot" or "gnuplot.ini".
>
> Option 2 has the additional advantage that you could use this
> mechanism to specify alternative initialization files.

Alternatively, you could add `-init-file FILE' (or `-rc-file'?).
`-init-file /dev/null' (or `-init-file nul' on Windows, probably)
would be the same as `-no-init-file'.

> Which would be more portable, and more useful - 
> a command line option or an environmental variable?

I'd prefer a command line option.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Do we need a -no-init-file option? [was Re: gnuplot-4.2.rc1: tutorial]

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 04 October 2006 09:48 am, Reiner Steib wrote:
> On Wed, Oct 04 2006, Ethan Merritt wrote:
>
> > Are you sure this isn't being added by some local TeX configuration
> > option on your machine?
>
> I found the culprit: it's "set encoding iso_8859_1" in `~/.gnuplot'.
> Does gnuplot have a "-no-init-file" option?  
> Such an option should be used when generating tutorial/eg*.tex.

We have no such option, but it is an interesting point.

I can see at least two way such an option could work 

1) gnuplot -no-init-file 
   If the command line option is present,
   skip the call to load_rcfile()  on line 563 of plot.c

2) setenv GNUPLOTRC "" ; gnuplot 
   The init file name is hard-coded into the string constant PLOTRC.
   We could provide an environment variable that overrides this.
   Setting it to "" or to any non-existent file name would 
   bypass the default names "~/.gnuplot" or "gnuplot.ini".

Option 2 has the additional advantage that you could use this
mechanism to specify alternative initialization files.

Which would be more portable, and more useful - 
a command line option or an environmental variable?


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: gnuplot-4.2.rc1: --program-suffix and gnuplot_x11

[Daniel J S. <dan...@ie...>]

Reiner Steib wrote:

> Thanks, the fix works for me.  Unless there's a more clean solution,
> I'd suggest to install Dan's patch.  The patch doesn't apply anymore
> to src/Makefile; attached you'll find an updated patch against rc1.

Thank you Reiner.  I've attached the patch you created to the S.F. entry.

Dan

Re: gnuplot-4.2.rc1: tutorial

[Reiner S. <rei...@im...>]

On Wed, Oct 04 2006, Ethan Merritt wrote:

> On Wednesday 04 October 2006 07:40 am, Reiner Steib wrote:
> I cannot reproduce this.  
>
> There is no mention of latin1 or inputencoding in any of the files
> in .../tutorial as distributed. The example *.plt files do not
> specify any particular encoding, and eg7.tex contains no such line
> when generated by the TeX installation here.

I didn't notice that tutorial/eg7.tex is generated.

> Are you sure this isn't being added by some local TeX configuration
> option on your machine?

I found the culprit: it's "set encoding iso_8859_1" in `~/.gnuplot'.

--8<---------------cut here---------------start------------->8---
$ cd tutorial
$ make clean
$ cat ~/.gnuplot
set encoding iso_8859_1
$ make eg7.tex
if test -x ../src/gnuplot ; then GNUPLOT_PS_DIR=../term/PostScript GNUPLOT_LIB=. GNUTERM=latex ../src/gnuplot eg7.plt ; else gnuplot eg7.plt ; fi
$ head -n6 eg7.tex
% GNUPLOT: LaTeX picture with Postscript
\begingroup
  % Encoding inside the plot.  In the header of your document, this encoding
  % should to defined, e.g., by using
  % \usepackage[latin1,<other encodings>]{inputenc}
  \inputencoding{latin1}%
$ rm ~/.gnuplot
$ make clean
$ make eg7.tex
$ head -n6 eg7.tex
% GNUPLOT: LaTeX picture with Postscript
\begingroup
  \makeatletter
  \providecommand\color[2][]{%
    \GenericError{(gnuplot) \space\space\space\@spaces}{%
      Package color not loaded in conjunction with
--8<---------------cut here---------------end--------------->8---

Does gnuplot have a "-no-init-file" option?  Such an option should be
used when generating tutorial/eg*.tex.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: gnuplot-4.2.rc1: tutorial

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 04 October 2006 07:40 am, Reiner Steib wrote:
> Hi,
>
> I tried to install gnuplot-4.2.rc1 on GNU/Linux (SUSE 9.2).
>
> tutorial/eg7.tex uses \inputencoding{latin1}

I cannot reproduce this.  

There is no mention of latin1 or inputencoding in any of the files
in .../tutorial as distributed. The example *.plt files do not
specify any particular encoding, and eg7.tex contains no such line
when generated by the TeX installation here.

Are you sure this isn't being added by some local TeX configuration
option on your machine?



> , but the master file 
> (tutorial.tex or header.tex) fails to add \usepackage[...]{inputenc}.
> The following patch fixed the problem for me (TeX system is TeX Live
> 2005):
>
> --8<---------------cut here---------------start------------->8---
> --- tutorial/header.tex.orig    2006-10-04 16:05:55.042788254 +0200
> +++ tutorial/header.tex 2006-10-04 15:38:22.030701292 +0200
> @@ -73,6 +73,8 @@
>  \usepackage{graphicx}
>  \usepackage{color}
>
> +\usepackage[latin1]{inputenc}
> +
>  % Margins
>  \sloppy
>  \setlength{\textwidth}{6.5in}
> --8<---------------cut here---------------end--------------->8---
>
> Bye, Reiner.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: gnuplot-4.2.rc1: --program-suffix and gnuplot_x11

[Reiner S. <rei...@im...>]

On Wed, Oct 04 2006, Juergen Wieferink wrote:

> Reiner Steib wrote:
>> [...] Therefore, I compile and install it using "--program-suffix"
>> as follows:
>
> This is bug [997481] with proposed fix [1531140].

[ For (my) convenience:
  http://sourceforge.net/tracker/index.php?func=detail&aid=997481&group_id=2055&atid=102055
  http://sourceforge.net/tracker/index.php?func=detail&aid=1531140&group_id=2055&atid=102055 ]

Thanks, the fix works for me.  Unless there's a more clean solution,
I'd suggest to install Dan's patch.  The patch doesn't apply anymore
to src/Makefile; attached you'll find an updated patch against rc1.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: gnuplot-4.2.rc1: --program-suffix and gnuplot_x11

[Juergen W. <wie...@fr...>]

Reiner Steib wrote:
> I tried to install gnuplot-4.2.rc1 on GNU/Linux (SUSE 9.2) on both
> i686 and x86_64.
>
> I want to install gnuplot to /usr/local which is shared between i686
> and x86_64 machines.  Therefore, I compile and install it using
> "--program-suffix" as follows:

This is bug [997481] with proposed fix [1531140].

Juergen

gnuplot-4.2.rc1: --program-suffix and gnuplot_x11

[Reiner S. <rei...@im...>]

Hi,

I tried to install gnuplot-4.2.rc1 on GNU/Linux (SUSE 9.2) on both
i686 and x86_64.

I want to install gnuplot to /usr/local which is shared between i686
and x86_64 machines.  Therefore, I compile and install it using
"--program-suffix" as follows:

--8<---------------cut here---------------start------------->8---
#!/bin/sh
conf_1="--enable-history-file --with-readline=gnu --enable-mouse"
suffix="4-2-rc1-`uname -m`"
set -e
./configure --program-suffix=-"$suffix" --prefix=${SOFT:-/usr/local} $conf_1
rm src/*.o
make
make install
--8<---------------cut here---------------end--------------->8---

I get:

,----
| /usr/local/libexec/gnuplot/4.2$ ls
| gnuplot_x11-4-2-rc1-i686  gnuplot_x11-4-2-rc1-x86_64
| 
| /usr/local/bin$ ls gnuplot-4-2-rc1-*
| gnuplot-4-2-rc1-i686  gnuplot-4-2-rc1-x86_64
`----

In /usr/local/bin, I have the following tiny wrapper:

,----[ gnuplot-4-2-rc1 ]
| #!/bin/sh
| exec "$0-`uname -m`" "$@"
`----

When I run gnuplot under X11, I get:

,----
| /usr/local/bin$ ./gnuplot-4-2-rc1-x86_64
| Expected X11 driver: /usr/local/libexec/gnuplot/4.2/gnuplot_x11
| Exec failed: No such file or directory
| See 'help x11' for more details
`----

,----
| $ ./gnuplot-4-2-rc1-i686
| 
|         G N U P L O T
|         Version 4.2 patchlevel rc1
|         last modified Wed Oct  4 15:32:29 CEST 2006
|         System: Linux 2.6.8-24.25-smp
| [...]
|         Send bug reports and suggestions to <gnu...@li...>
| 
| Expected X11 driver: /usr/local/libexec/gnuplot/4.2/gnuplot_x11
| Exec failed: No such file or directory
| See 'help x11' for more details
| Applying settings from ~/.gnuplot:
|   encoding, samples, zero
| 
| 
| Terminal type set to 'x11'
| gnuplot> test
| Expected X11 driver: /usr/local/libexec/gnuplot/4.2/gnuplot_x11
| Exec failed: No such file or directory
| See 'help x11' for more details
`----

I'd say this is a bug: Either the installation routine should install
gnuplot_x11 as libexec/gnuplot/4.2-${program_suffix}/gnuplot_x11 or
the main program should search for
/usr/local/libexec/gnuplot/4.2/gnuplot_x11-4-2-${program_suffix} as
well.

BTW, I can work around this problem with...
,----
| cd /usr/local/libexec/gnuplot/4.2
| ln -s gnuplot_x11-4-2-rc1-i686 gnuplot_x11
`----
...  but this only works accidentally for i686 and x86_64.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

gnuplot-4.2.rc1: tutorial

[Reiner S. <rei...@im...>]

Hi,

I tried to install gnuplot-4.2.rc1 on GNU/Linux (SUSE 9.2).

tutorial/eg7.tex uses \inputencoding{latin1}, but the master file
(tutorial.tex or header.tex) fails to add \usepackage[...]{inputenc}.
The following patch fixed the problem for me (TeX system is TeX Live
2005):

--8<---------------cut here---------------start------------->8---
--- tutorial/header.tex.orig    2006-10-04 16:05:55.042788254 +0200
+++ tutorial/header.tex 2006-10-04 15:38:22.030701292 +0200
@@ -73,6 +73,8 @@
 \usepackage{graphicx}
 \usepackage{color}
 
+\usepackage[latin1]{inputenc}
+
 % Margins
 \sloppy
 \setlength{\textwidth}{6.5in}
--8<---------------cut here---------------end--------------->8---

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Linked Axes: I need to extract xtics positions.

[Daniel F. <boy...@gm...>]

Hi Petr,

Maybe I should explain the proposed algorithm for making 'quasi- 
linked' axes script.

#1 Using the transform equation that links the x1 and x2 axes,  
convert the x1 data points to x2 data points units.

#2 The new x2 data points need to be spaced nicely, so use gnuplot to  
calculate how to space them.

#3 Use the transform equation again, but this time in reverse to  
calculate the x1 co-ordinates at which the 'nicely spaced' x2 tics  
will be placed.

#4 use set xtics("x2_a" x1_a, "x2_b" x1_b ... etc)

where x2_a is the x2 value at which we have first x2tic mark. x1_a is  
the x1 co-ordinate at which this x2_a tic mark is placed. x2_b is the  
x2 value at which we have the second x2tic mark. x1_b is the x1 co- 
ordinate at which the x2_b tic mark is placed... etc

I need to use gnuplot to nicely space the x2 values in step #2.

> Would it suffice to have GPVAL_X_TICS_FROM, GPVAL_X_TICS_TO,  
> GPVAL_Y_TICS_FROM, etc.?

It would work if I could get gnuplot to give me GPVAL_X_TICS_FROM,  
GPVAL_X_TICS_TO and GPVAL_X_TICS_SPACING (assuming that spacing is  
linear - which is good enough for me!)

Dan.


On 4 Oct 2006, at 13:06, Petr Mikulik wrote:

>> I'm trying to experiment with 'linked axes' in gnuplot. Rather  
>> than delving straight into the code (right away) I first want to  
>> test a few things by making a 'linked axes' simple script that  
>> controls gnuplot. To make it work, I need to know the positions at  
>> which gnuplot will (or has chosen to) place tics marks on the x1  
>> axis. Is is possible to extract this data using gnuplot?
>
> Would it suffice to have GPVAL_X_TICS_FROM, GPVAL_X_TICS_TO,  
> GPVAL_Y_TICS_FROM, etc.?
>
>> Alternatively a more general approach: is there a command line  
>> function were I can pass in a column of data (text file) upon  
>> which it will return the location of where gnuplot with place tic  
>> marks? Would such a funciton be simple for anyone here to quickly  
>> pull together. It would take me quite a while to get use to the  
>> gnuplot code base to do so.
>
> set macros
> a=system("echo '1,2,4,8,16,32,64,128,256,512,1024'")  # or cat a file
> set xtics (@a)
> plot x
>
> ---
> PM

Re: Linked Axes: I need to extract xtics positions.

[Petr M. <mi...@ph...>]

> I'm trying to experiment with 'linked axes' in gnuplot. Rather than 
> delving straight into the code (right away) I first want to test a few 
> things by making a 'linked axes' simple script that controls gnuplot. To 
> make it work, I need to know the positions at which gnuplot will (or has 
> chosen to) place tics marks on the x1 axis. Is is possible to extract this 
> data using gnuplot?

Would it suffice to have GPVAL_X_TICS_FROM, GPVAL_X_TICS_TO, 
GPVAL_Y_TICS_FROM, etc.?

> Alternatively a more general approach: is there a command line function 
> were I can pass in a column of data (text file) upon which it will return 
> the location of where gnuplot with place tic marks? Would such a funciton 
> be simple for anyone here to quickly pull together. It would take me quite 
> a while to get use to the gnuplot code base to do so.

set macros
a=system("echo '1,2,4,8,16,32,64,128,256,512,1024'")  # or cat a file
set xtics (@a)
plot x

---
PM

Linked Axes: I need to extract xtics positions.

[Daniel F. <boy...@gm...>]

Hello,

I'm trying to experiment with 'linked axes' in gnuplot. Rather than  
delving straight into the
code (right away) I first want to test a few things by making a  
'linked axes' simple script that
controls gnuplot. To make it work, I need to know the positions at  
which gnuplot will (or
has chosen to) place tics marks on the x1 axis. Is is possible to  
extract this data using
gnuplot?

Alternatively a more general approach: is there a command line  
function were I can pass in a
column of data (text file) upon which it will return the location of  
where gnuplot with place tic marks? Would such a funciton be simple  
for anyone here to quickly pull together. It would take me quite a  
while to get use to the gnuplot code base to do so.

Cheers,

Dan.

Re: [Fwd: Re: gnuplot numerical errors on Intel MacBook]

[CM <mon...@gm...>]

I have verified that the latest patch, the one that does everything at
configuration time, works on my Intel MacBook Pro.

Thanks, Daniel!

+1

- C

On 9/28/06, Daniel J Sebald <dan...@ie...> wrote:
>
> Hans-Bernhard Br=F6ker wrote:
> > Daniel J Sebald wrote:
> >
> >
> >>Probably so.  If this is the most up-to-date documentation:
> >
> >
> >>
> http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/l=
gamma.3.html
> >
> >
> >>there is no mention of a variable signgam.
> >
> >
> > And that's a solid bug in any OS math library that purports to implemen=
t
> > C99 or any recent level of Unix standard compliance.  lgamma() is
> > required to be there, and it's equally required to have a signgam to go
> > with it.
> >
> >  > So perhaps it has no meaning anymore for Apple's platform.
> >
> > That's not Appple's decision to make.
> >
> >  > Why they would still have the variable in
> >
> >>the library if that were the case, I'm not sure.
> >
> >
> > They must have it, and they must use it as defined in all applicable
> > standards.
>
> Well, thanks for pointing out the standard, didn't know there was a C99
> standard.  However, if this is the standard documentation at:
>
> http://www.open-std.org/JTC1/SC22/WG14/www/standards
>
> under WG14 N1124 (it's a PDF file), then I don't immediately see any
> indication that lgamma() requires there be an associated signgam
> variable.  In fact, there is no such signgam in the document anywhere.  T=
he
> documentation appears just as listed on the apple websight.
>
> There isn't even a gamma() function in C99.  I'm guessing the concept is
> to move away from signgam, I believe, for which the non-threadedness may
> have played a factor in their decision.
>
> So, that first patch I have on SourceForge is the C99 version (just tgamm=
a
> or lgamma).  The second patch is the "alright, we'll be nice to all you
> behind the curve computer users out there" (which is probably somewhere n=
ear
> 99.73%) version.
>
> Dan
>



--=20
:(){ :|:&};:

Re: Gentlemen, start your engines...

[<br...@ph...>]

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.

Re: Gentlemen, start your engines...

[<tim...@en...>]

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.

Re: Gentlemen, start your engines...

[<tim...@en...>]

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

Re: Gentlemen, start your engines...

[<tim...@en...>]

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

Re: Gentlemen, start your engines...

[<br...@ph...>]

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?

Re: Configuration bug: should not make in .../share/LaTeX/ if TeX is =?utf-8?q?not=09present?=

[Ethan M. <merritt@u.washington.edu>]

On Monday 02 October 2006 02:46 am, Timoth=C3=A9e Lecomte wrote:
> > I'm not very good at this sort of build-time dependency.
> > Can someone fix it so that the descent into .../share/LaTeX
> > doesn't happen if TeX is not insalled?
>
> Here is a patch that builds share/LaTeX only when --with-kpsexpand is
> given

Thanks.
I have thought about this some more, and concluded that
this is really a separate issue from --with-kpsexpand=20

=2D-with-kpsexpand allows gnuplot itself to try to run kpsexpand
at run time when searching for fonts, and is not intrinsically
linked to producing TeX output.

The problem at hand is not a run-time issue. It is a question
of trying to install an include file used by the epslatex driver.
It would be harmless to build this include file even for
installation on systems where TeX is not used.  In fact that is
probably the right thing to do. =20

So when building a distribution package we want to separate the
build environment from the eventual run-time environment.
The existing configure scripts seem to detect whether or not emacs
is present, and skip pieces of the installation if it is not.
Can that same mechanism be used to skip share/LaTeX if
TeX is not installed?


> (I cannot post a patch to the sourceforge page, can this be=20
> solved too ?)

I hadn't realized this was separate from the cvs access permissions.
Perhaps it requires some added level of authorization?


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Gentlemen, start your engines...

[Petr M. <mi...@ph...>]

>> 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

Re: Configuration bug: should not make in .../share/LaTeX/ if TeX is not present

[<tim...@en...>]

Ethan A Merritt wrote:
> On Sunday 01 October 2006 04:39 pm, Joe Koski wrote:
>  =20
>> I'm saying the latter. LaTeX is not usually installed on Macs, and, fo=
r
>> example, octave just ignores installing the octave LaTeX documentation=
 on
>> Macs. I don't think kpsexpand exists either
>>    =20
>
> kpsexpand is part of TeX.
>
>  =20
>> I am always getting error messages about not finding kpsexpand
>>    =20
>
> I used to get those messages too, clogging up my system log files.
> I only recently learned that they were coming from gnuplot, and
> tried to fix it.
>
> It is *supposed* to be a configuration option now,
>    ./configure --with-kpsexpand
>    =20
> I thought that fixed everything, but as you have found,
> the .../share/LaTeX Makefile is still a problem. =20
>
> I'm not very good at this sort of build-time dependency.
> Can someone fix it so that the descent into .../share/LaTeX
> doesn't happen if TeX is not insalled?
>  =20
Here is a patch that builds share/LaTeX only when --with-kpsexpand is=20
given (I cannot post a patch to the sourceforge page, can this be solved=20
too ?)

Best regards,

Timoth=E9e