Menu
▾
▴
gnuplot-beta
|
From: Dima K. <gn...@di...> - 2017-08-17 20:52:11
|
Here're two minor, but useful patches: 1. If we can't find a helper binary (gnuplot_x11, gnuplot_qt), the error message now states which environment variable can be used to redirect it 2. The build was broken on a recent Debian system: we were calling XInitThreads(), but not linking in -lX11. The patch adds the linkage |
|
From: Ethan A M. <merritt@u.washington.edu> - 2017-08-17 21:28:32
|
On Thursday, 17 August, 2017 13:51:55 Dima Kogan wrote: > Here're two minor, but useful patches: > > 1. If we can't find a helper binary (gnuplot_x11, gnuplot_qt), the error > message now states which environment variable can be used to redirect it Thanks for that one. > 2. The build was broken on a recent Debian system: we were calling > XInitThreads(), but not linking in -lX11. The patch adds the linkage Sigh. This keeps coming back and back and back. Adding -lX11 fixes most linux installations but breaks everyone else. See for example https://sourceforge.net/p/gnuplot/bugs/1764/ The problem comes from API breakage in wxgtk3. But not all platforms use gtk to support wxWidgets. It is basically impossible to autodetect whether the locally installed wxWidgets does or does not require this extra flag. So instead we note the problem prominently in the Release Notes. It is the first item in KNOWN ISSUES. Ethan -- Ethan A Merritt Biomolecular Structure Center, K-428 Health Sciences Bldg MS 357742, University of Washington, Seattle 98195-7742 |
|
From: Dima K. <gn...@di...> - 2017-08-18 02:32:56
|
On Thu, Aug 17, 2017, at 14:13, Ethan A Merritt wrote: > > 2. The build was broken on a recent Debian system: we were calling > > XInitThreads(), but not linking in -lX11. The patch adds the linkage > > Sigh. This keeps coming back and back and back. > Adding -lX11 fixes most linux installations but breaks everyone else. > > See for example https://sourceforge.net/p/gnuplot/bugs/1764/ OK, I read your links, but it's not obvious how it breaks everyone else. Is the concern that some platforms have wx, but not X11, so the link to libX11 will fail? What if instead of linking to -lX11 we link to $LIBRARIES_FOR_X? |
|
From: sfeam <sf...@us...> - 2017-08-18 04:04:17
|
On Thursday, 17 August 2017 19:17:05 Dima Kogan wrote: > On Thu, Aug 17, 2017, at 14:13, Ethan A Merritt wrote: > > > > 2. The build was broken on a recent Debian system: we were calling > > > XInitThreads(), but not linking in -lX11. The patch adds the linkage > > > > Sigh. This keeps coming back and back and back. > > Adding -lX11 fixes most linux installations but breaks everyone else. > > > > See for example https://sourceforge.net/p/gnuplot/bugs/1764/ > > OK, I read your links, but it's not obvious how it breaks everyone else. > Is the concern that some platforms have wx, but not X11, so the link to > libX11 will fail? What if instead of linking to -lX11 we link to > $LIBRARIES_FOR_X? Doesn't that just push the same problem down or up one level? The question then becomes how do you figure out what to put in $LIBRARIES_FOR_X. Ethan |
|
From: Dima K. <gn...@di...> - 2017-08-20 04:29:44
|
sfeam <sf...@us...> writes: > On Thursday, 17 August 2017 19:17:05 Dima Kogan wrote: >> On Thu, Aug 17, 2017, at 14:13, Ethan A Merritt wrote: >> >> > > 2. The build was broken on a recent Debian system: we were calling >> > > XInitThreads(), but not linking in -lX11. The patch adds the linkage >> > >> > Sigh. This keeps coming back and back and back. >> > Adding -lX11 fixes most linux installations but breaks everyone else. >> > >> > See for example https://sourceforge.net/p/gnuplot/bugs/1764/ >> >> OK, I read your links, but it's not obvious how it breaks everyone else. >> Is the concern that some platforms have wx, but not X11, so the link to >> libX11 will fail? What if instead of linking to -lX11 we link to >> $LIBRARIES_FOR_X? > > Doesn't that just push the same problem down or up one level? > The question then becomes how do you figure out what to put > in $LIBRARIES_FOR_X. I think this should be fine. On platforms where we ran ./configure --with-x (default usually) then $LIBRARIES_FOR_X would contain "-lX11", and the proposed link command would work. On platforms X11 isn't available, $LIBRARIES_FOR_X should evaluate to "", which would be fine. Presumably, the same should happen if we ./configure --without-x, but that doesn't work. This is probably a bug in the build system, but this is a separate issue. I'm attaching the updated patch |
|
From: Dima K. <gn...@di...> - 2017-09-04 18:50:20
|
Dima Kogan <gn...@di...> writes: > sfeam <sf...@us...> writes: > >> On Thursday, 17 August 2017 19:17:05 Dima Kogan wrote: >>> On Thu, Aug 17, 2017, at 14:13, Ethan A Merritt wrote: >>> >>> > > 2. The build was broken on a recent Debian system: we were calling >>> > > XInitThreads(), but not linking in -lX11. The patch adds the linkage >>> > >>> > Sigh. This keeps coming back and back and back. >>> > Adding -lX11 fixes most linux installations but breaks everyone else. >>> > >>> > See for example https://sourceforge.net/p/gnuplot/bugs/1764/ >>> >>> OK, I read your links, but it's not obvious how it breaks everyone else. >>> Is the concern that some platforms have wx, but not X11, so the link to >>> libX11 will fail? What if instead of linking to -lX11 we link to >>> $LIBRARIES_FOR_X? >> >> Doesn't that just push the same problem down or up one level? >> The question then becomes how do you figure out what to put >> in $LIBRARIES_FOR_X. Pinging this thread before I forget about it. Can we please merge the patch? On systems where X11 is available, $LIBRARIES_FOR_X will contain the X11 link flags, so we'll link in the appropriate library, and things will work. On systems where X11 is not available, $LIBRARIES_FOR_X will be "", so nothing extra will be linked in, and things will keep functioning as before. |
|
From: sfeam <sf...@us...> - 2017-09-04 19:26:49
|
On Monday, 04 September 2017 11:50:11 Dima Kogan wrote: > Dima Kogan <gn...@di...> writes: > > > sfeam <sf...@us...> writes: > > > >> On Thursday, 17 August 2017 19:17:05 Dima Kogan wrote: > >>> On Thu, Aug 17, 2017, at 14:13, Ethan A Merritt wrote: > >>> > >>> > > 2. The build was broken on a recent Debian system: we were calling > >>> > > XInitThreads(), but not linking in -lX11. The patch adds the linkage > >>> > > >>> > Sigh. This keeps coming back and back and back. > >>> > Adding -lX11 fixes most linux installations but breaks everyone else. > >>> > > >>> > See for example https://sourceforge.net/p/gnuplot/bugs/1764/ > >>> > >>> OK, I read your links, but it's not obvious how it breaks everyone else. > >>> Is the concern that some platforms have wx, but not X11, so the link to > >>> libX11 will fail? What if instead of linking to -lX11 we link to > >>> $LIBRARIES_FOR_X? > >> > >> Doesn't that just push the same problem down or up one level? > >> The question then becomes how do you figure out what to put > >> in $LIBRARIES_FOR_X. > > Pinging this thread before I forget about it. Can we please merge the > patch? > > On systems where X11 is available, $LIBRARIES_FOR_X will contain the X11 > link flags, so we'll link in the appropriate library, and things will > work. I do not think this is correct. What about systems where X is "available" but is not used for wxt? I think that is true for both OSX and Windows. My recollection is that putting -LX11 in the build flags broke OSX. For that matter, even on my linux systems that still use wxgtk 2.8 rather than 3.0, the -lX11 is not needed. In this case it doesn't break anything, but still it's annoying to include a library dependency that isn't even used. gnuplot itself does not use the X libraries. I still think this is a wxgtk configuration error and not something that gnuplot can fix on its own. Ethan > > On systems where X11 is not available, $LIBRARIES_FOR_X will be "", so > nothing extra will be linked in, and things will keep functioning as > before. |
|
From: Dima K. <gn...@di...> - 2017-09-04 19:32:33
|
sfeam <sf...@us...> writes: >> Pinging this thread before I forget about it. Can we please merge the >> patch? >> >> On systems where X11 is available, $LIBRARIES_FOR_X will contain the >> X11 link flags, so we'll link in the appropriate library, and things >> will work. > > I do not think this is correct. What about systems where X is > "available" but is not used for wxt? I think that is true for both OSX > and Windows. My recollection is that putting -LX11 in the build flags > broke OSX. I'l like to get confirmation from somebody who actually uses OSX. > I still think this is a wxgtk configuration error and not something > that gnuplot can fix on its own. Maybe. But the current state of affairs is that on Debian (and probably every other linux distro) a simple ./prepare; ./configure; make sequence fails. It doesn't matter whose bug this is we should try to work around it. |
|
From: sfeam <sf...@us...> - 2017-09-04 21:20:17
|
On Monday, 04 September 2017 12:32:25 Dima Kogan wrote: > sfeam <sf...@us...> writes: > > >> Pinging this thread before I forget about it. Can we please merge the > >> patch? > >> > >> On systems where X11 is available, $LIBRARIES_FOR_X will contain the > >> X11 link flags, so we'll link in the appropriate library, and things > >> will work. > > > > I do not think this is correct. What about systems where X is > > "available" but is not used for wxt? I think that is true for both OSX > > and Windows. My recollection is that putting -LX11 in the build flags > > broke OSX. > > I'l like to get confirmation from somebody who actually uses OSX. > > > > I still think this is a wxgtk configuration error and not something > > that gnuplot can fix on its own. > > Maybe. But the current state of affairs is that on Debian (and probably > every other linux distro) a simple > > ./prepare; ./configure; make > > sequence fails. It doesn't matter whose bug this is we should try to > work around it. It does not fail here (Mageia 4/5/6). But OK, let's try it out in 5.3 I hope you don't mind if I cc any complaints from the OSXers in your direction :) Ethan |
|
From: Dima K. <gn...@di...> - 2017-09-05 03:38:07
|
sfeam <sf...@us...> writes: > I hope you don't mind if I cc any complaints from the OSXers in your > direction :) Sure :) |
