Menu
▾
▴
gnuplot-beta
|
From: Reiner S. <rei...@im...> - 2006-10-04 14:41:13
|
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/
|
|
From: Juergen W. <wie...@fr...> - 2006-10-04 14:55:58
|
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 |
|
From: Reiner S. <rei...@im...> - 2006-10-04 16:18:00
Attachments:
prefixsuffix-djs-rsteib-2006-10-04.patch
|
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/ |
|
From: Daniel J S. <dan...@ie...> - 2006-10-04 17:06:56
|
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 |
|
From: Reiner S. <rei...@im...> - 2006-10-05 17:40:31
|
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/
|
|
From: Ethan M. <merritt@u.washington.edu> - 2006-10-05 18:08:02
|
I don't think this is the right approach, because it does not truly allow for the general case of a mixed architecture environment. What if gnuplot_x11 is running on a different machine than gnuplot? What if gnuplot was built 64-bit, but gnuplot_x11 was built 32-bit? What I have seen work for other program packages is to leave the name of the executable unchanged, but install multiple architecture-specific executables into parallel directories. The correct executable is selected by virtue of the PATH set for your current session. In the case of gnuplot you could also use the GNUPLOT_DRIVER_DIR environmental variable to control this, but you'd have to set it in an architecture-dependent fashion via your login script. In other words, if we are to do this at all, I think the correct approach is to leave the file name of gnuplot_x11 unchanged, but teach the install procedure to create a directory name from the architecture type. Or just add a set of instructions for manual installation of this one component in a mixed-architecture environment. > In my case, I used --program-suffix for a multi-architecture build. > But previously I also used --program-suffix="-patched" to distinguish > my modified version from the upstream version. IIRC I also had to > symlink gnuplot_x11 accordingly back then. I just leave the patched executable in the patched source directory where it was built, and setenv GNUPLOT_DRIVER_DIR to point there if I want to test it. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Reiner S. <rei...@im...> - 2006-10-05 17:54:21
|
On Wed, Oct 04 2006, Reiner Steib wrote: > [ 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. WRT [1531140] ... In my case, I used --program-suffix for a multi-architecture build. But previously I also used --program-suffix="-patched" to distinguish my modified version from the upstream version. IIRC I also had to symlink gnuplot_x11 accordingly back then. I.e. I agree with Dan's comment: ,----[ Date: 2006-10-04 14:32, Sender: sebald ] | In the bug report, Hans states that adding the suffix to gnuplot-x11 | isn't necessary. However, I'd argue it is. The person who uses | "program-suffix" is someone who might create a special version of | the program that has a recent patch or something. If that patch | effected gplt_x11.c then it would be nice to have the two different | versions of gnuplot_x11 and gnuplot_x11-suffix. E.g., someone wants | the most recent official release and one with a great new feature, | "gnuplot" and "gnuplotspif". `---- Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ |
|
From: Daniel J S. <dan...@ie...> - 2006-10-05 18:57:43
|
Are there two different situations? One is sort of a custom version of gnuplot_x11, the other is more a general and portable version of gnuplot_x11. Should there be a way to change the name of "gnuplot_x11"? For custom versions perhaps? There is this approach: > I just leave the patched executable in the patched source > directory where it was built, and setenv GNUPLOT_DRIVER_DIR > to point there if I want to test it. but that isn't exactly the most proficient method. I'd have to keep changing GNUPLOT_DRIVER_DIR if I want to alternate between "gnuplot" and "mygnuplot", and I wonder if I can run both at the same time. From the standpoint of a multiuser environment like a computer center, that approach isn't so much "automating" the process as it is just shifting the burdon of configuring things to a later point. For the person who is not the one building gnuplot it is difficult to remember such things. If customization means that "gnuplot_x11" name should change, does there need to be independent control of name alteration for "gnuplot" and "gnuplot_x11"? Probably not. If the user wants that kind of sophistication as a configure option then I'd think the user is smart enough to be moving the executables to desired directories. There definitely needs to be multi-environment support, but I would argue that that should be taken care of without the users direction. Shouldn't have to think about that. I would think there are autoconf commands for that sort of thing. It is hard to say what to do here. My gut feeling is that there should be two methods of setting this up. One other comment is that I've tended to not so much think of gnuplot_x11 as being a separate program. If we are at the point of considering gnuplot-x11 running on one machine and gnuplot on another, it might then be pertinent to start talking version numbers and having gnuplot check that its version is compatible with the gnuplot_x11 version. Dan Ethan Merritt wrote: > I don't think this is the right approach, because it does > not truly allow for the general case of a mixed architecture > environment. What if gnuplot_x11 is running on a different > machine than gnuplot? What if gnuplot was built 64-bit, but > gnuplot_x11 was built 32-bit? > > What I have seen work for other program packages is to leave > the name of the executable unchanged, but install multiple > architecture-specific executables into parallel directories. > The correct executable is selected by virtue of the PATH > set for your current session. In the case of gnuplot you > could also use the GNUPLOT_DRIVER_DIR environmental variable > to control this, but you'd have to set it in an > architecture-dependent fashion via your login script. > > In other words, if we are to do this at all, I think the > correct approach is to leave the file name of gnuplot_x11 > unchanged, but teach the install procedure to create a > directory name from the architecture type. Or just add > a set of instructions for manual installation of this > one component in a mixed-architecture environment. > > >>In my case, I used --program-suffix for a multi-architecture build. >>But previously I also used --program-suffix="-patched" to distinguish >>my modified version from the upstream version. IIRC I also had to >>symlink gnuplot_x11 accordingly back then. > > > > -- Dan Sebald phone: 608 256 7718 email: daniel DOT sebald AT ieee DOT org URL: http://webpages DOT charter DOT net/dsebald/ |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-10-05 19:28:08
|
On Thursday 05 October 2006 12:07 pm, Daniel J Sebald wrote: > > I just leave the patched executable in the patched source > > directory where it was built, and setenv GNUPLOT_DRIVER_DIR > > to point there if I want to test it. > > but that isn't exactly the most proficient method. I'd have to keep > changing GNUPLOT_DRIVER_DIR if I want to alternate between "gnuplot" > and "mygnuplot" Huh? We're talking about gnuplot_x11, not gnuplot. It doesn't make any difference which gnuplot executable you are using. > From the standpoint of a multiuser environment like a computer > center Stop right there. The issue is not multi-user; the issue is multiple machines seen by *one* user. I have two different machines at my desk (x86 and amd64) and have gnuplot installed also on 64-bit alpha and both 32- and 64- bit irix machines on the same network. Various windows on my desktop may be logged in to various of these machines. Fun, huh? And if my login directory is shared via NFS by some or all of these architectures, then the appropriate run path has to be constructed every time I log in, since if I log in on a 32-bit Irix workstation the 64-bit linux executable isn't going to do me much good. The last thing I want is to have to remember to type gnuplot_amd64 instead of gnuplot_irix5 depending on which machine is listening to the window I'm typing into. The name should always be "gnuplot", and the path should make it 'just work'. > One other comment is that I've tended to not so much think of > gnuplot_x11 as being a separate program. If we are at the point of > considering gnuplot-x11 running on one machine and gnuplot on > another, it might then be pertinent to start talking version numbers > and having gnuplot check that its version is compatible with the > gnuplot_x11 version. That's a totally separate issue. Version mis-match is already a problem on a single machine. Usually you get an error message "gnuplot_x11: protocol error", which isn't so bad as error messages go. > > Dan > > Ethan Merritt wrote: > > I don't think this is the right approach, because it does > > not truly allow for the general case of a mixed architecture > > environment. What if gnuplot_x11 is running on a different > > machine than gnuplot? What if gnuplot was built 64-bit, but > > gnuplot_x11 was built 32-bit? > > > > What I have seen work for other program packages is to leave > > the name of the executable unchanged, but install multiple > > architecture-specific executables into parallel directories. > > The correct executable is selected by virtue of the PATH > > set for your current session. In the case of gnuplot you > > could also use the GNUPLOT_DRIVER_DIR environmental variable > > to control this, but you'd have to set it in an > > architecture-dependent fashion via your login script. > > > > In other words, if we are to do this at all, I think the > > correct approach is to leave the file name of gnuplot_x11 > > unchanged, but teach the install procedure to create a > > directory name from the architecture type. Or just add > > a set of instructions for manual installation of this > > one component in a mixed-architecture environment. > > > >>In my case, I used --program-suffix for a multi-architecture build. > >>But previously I also used --program-suffix="-patched" to > >> distinguish my modified version from the upstream version. IIRC I > >> also had to symlink gnuplot_x11 accordingly back then. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Daniel J S. <dan...@ie...> - 2006-10-05 20:04:49
|
Ethan Merritt wrote: > On Thursday 05 October 2006 12:07 pm, Daniel J Sebald wrote: > >> > I just leave the patched executable in the patched source >> > directory where it was built, and setenv GNUPLOT_DRIVER_DIR >> > to point there if I want to test it. >> >>but that isn't exactly the most proficient method. I'd have to keep >>changing GNUPLOT_DRIVER_DIR if I want to alternate between "gnuplot" >>and "mygnuplot" > > > Huh? We're talking about gnuplot_x11, not gnuplot. It doesn't > make any difference which gnuplot executable you are using. Yes, unless the source file gplt_x11.c in gnuplot's src subdirectory is one of the files that is altered. It hasn't happened in a major way for a while, but as recent as 7/21 was a small change. >>From the standpoint of a multiuser environment like a computer >>center > > > Stop right there. The issue is not multi-user; the issue is > multiple machines seen by *one* user. > > I have two different machines at my desk (x86 and amd64) and > have gnuplot installed also on 64-bit alpha and both > 32- and 64- bit irix machines on the same network. > Various windows on my desktop may be logged in to various of > these machines. Fun, huh? Right, I didn't state that clearly, I too was thinking a networked environment where a user might log in remotely or something. > > And if my login directory is shared via NFS by some or all of > these architectures, then the appropriate run path has to > be constructed every time I log in, since if I log in on > a 32-bit Irix workstation the 64-bit linux executable isn't > going to do me much good. > > The last thing I want is to have to remember to type > gnuplot_amd64 instead of gnuplot_irix5 depending on which > machine is listening to the window I'm typing into. > The name should always be "gnuplot", and the path should make > it 'just work'. But that isn't custom. These versions are essentially the same version on a different environment. I said there definitely needs to be the behavior you are describing. All I'm saying is that it is conceivable that a person might want to have two slightly different version of gnuplot around with two different names. This --program-suffix=? syntax seems like something for that. The worst that can happen is that there ends up being a "gnuplot_x11" and "gnuplot_x11_spiff" that are the same exact program. On the other hand, --program-suffix=? seems like a clumsy way of dealing with the multi-environment issue you are talking about; GNUPLOT_DRIVER_DIR is the big winner there. (I wouldn't advocate GNUPLOT_DRIVER_DIR as a cure all for the case of creating custom or development versions.) But GNUPLOT_DRIVER_DIR is run time; what about during build? Well, from what I understand, the autoconf configuration method currently in place doesn't yet build good directory structure to make the multi-environment process seamless. We need something like /usr/local/lib<environment>/gnuplot/VERSION which gets <environment> from, say, an environment variable defined on the machine in which gnuplot is compiled? Am I right on that? Dan |
|
From: Hans-Bernhard B. <br...@ph...> - 2006-10-05 20:51:08
|
On Wed, 4 Oct 2006, 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. This, rather than the interaction of autoconf's --program-suffix mechanism with how we install gnuplot_x11, is the root of your problem. I've worked in an NFS-mounted home directory shared among *completely* different platforms (x86/Linux, Alpha/OSF1 and Mips/ULTRIX). My experience is that the only way to get that working properly is --exec-prefix, because that's exactly what this option is designed to do. One --prefix fits all, but each platform gets its own --exec-prefix. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Daniel J S. <dan...@ie...> - 2006-10-05 21:07:06
|
Hans-Bernhard Broeker wrote: > On Wed, 4 Oct 2006, 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. > > > This, rather than the interaction of autoconf's --program-suffix mechanism > with how we install gnuplot_x11, is the root of your problem. I've worked > in an NFS-mounted home directory shared among *completely* different > platforms (x86/Linux, Alpha/OSF1 and Mips/ULTRIX). My experience is that > the only way to get that working properly is --exec-prefix, because that's > exactly what this option is designed to do. > > One --prefix fits all, but each platform gets its own --exec-prefix. > Hans is ahead of me on this one. I was just looking through the list of variables: http://www.gnu.org/software/autoconf/manual/html_node/Installation-Directory-Variables.html#Installation-Directory-Variables Does the following help to solve any problems: ./configure --libexecdir=\${exec_prefix}/lib$(uname -i)exec What that does is define libexecdir = ${exec_prefix}/libi386exec in my src/Makefile rather than libexecdir = ${exec_prefix}/libexec Dan |
|
From: Reiner S. <rei...@im...> - 2006-10-05 21:58:58
|
On Thu, Oct 05 2006, Hans-Bernhard Broeker wrote:
> On Wed, 4 Oct 2006, Reiner Steib wrote:
>> I want to install gnuplot to /usr/local which is shared between i686
>> and x86_64 machines. =20
>
> This, rather than the interaction of autoconf's --program-suffix mechan=
ism
> with how we install gnuplot_x11, is the root of your problem.
I disagree. Forget about my multi-architecture reasons[1] for a moment
and just consider a simple =BB./configure --program-suffix=3D-42=AB. You=
'll
get the very same problem...
,----
| $ gnuplot-42=20
| Expected X11 driver: /usr/local/libexec/gnuplot/4.2/gnuplot_x11
| Exec failed: No such file or directory
| See 'help x11' for more details
`----
... because there is only "gnuplot_x11-42" in
/usr/local/libexec/gnuplot/4.2/:
,----
| $ ls /usr/local/libexec/gnuplot/4.2/
| gnuplot_x11-42
`----
> My experience is that the only way to get that working properly is
> --exec-prefix, because that's exactly what this option is designed
> to do.
>
> One --prefix fits all, but each platform gets its own --exec-prefix.
I will keep this in mind. Thanks.
Bye, Reiner.
[1] If you need a reason: The user should get the distribution's
version of gnuplot, but I want to offer 4.2 for those who need the
new features.
--=20
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
|
|
From: Hans-Bernhard B. <br...@ph...> - 2006-10-05 21:34:52
|
On Thu, 5 Oct 2006, Daniel J Sebald wrote:
> Does the following help to solve any problems:
>
> ./configure --libexecdir=\${exec_prefix}/lib$(uname -i)exec
No. It solves only half the problem, because it still writes the main
gnuplot executable to a directory shared by multiple architectures. The
correct solution, if you want to base it on uname -i output, would be more
like this:
[if you're root:]
./configure --exec-prefix=/usr/local/$(uname -i)
[otherwise:]
./configure --prefix=$HOME --exec-prefix=$HOME/$(uname -i)
--
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.
|
