Menu
▾
▴
#503 gnuplot is built with g++ even when not needed
Do to the way automake works, gnuplot is built with g++ (or another C++ compiler) even when vxworks is disabled.
On a linux/gnu system this has the consequence that the gnuplot binary quite unnecessarily depends on libstdc++.so.
Things are, however, much worse on systems where there is no C++ compiler (or only a broken one).
Attached is a small patch addressing this problem. The solution is not perfect becaus automake produces warnings. The resulting src/Makefile.in is, however, correct.
patch to build non-vxworks gnuplot with gcc (not g++)
Logged In: YES
user_id=1333817
Originator: NO
I assume you mean 'wxt' instead of 'vxworks' ;)
I have a couple of remarks:
1) there is a test in 'configure' for a C++ compiler. If there's no such compiler or a not-working one, gnuplot will still be built, without the wxt terminal
2) I really don't understand how your patch could solve the problem, I don't see what it effectively changes
Logged In: YES
user_id=1244989
Originator: YES
The point is, that even if vxt is not used in the actual build, the Makefile.in produced by automake uses g++ to link gnuplot (and I think there is no way around this).
With the patch either gnuplot_novx is built from C-only sources and thus linked with gcc, or gnuplot_vx id built from C and C++ sources and thus linked with g++.
In a second step this _vx or _novx binary is $(LN_S)'d ("ln -s", "ln", or "cp -p" depending on the system) to gnuplot which is then installed.
An alternative would be to build either gnuplot_vx or gnuplot_novx and rename it during or after install. Doing this such that "install-strip" and "--program-transform-name" still work as expected seems to be considerably more complicated (and would use more knowledge of automake's internals).
Logged In: YES
user_id=1333817
Originator: NO
>The point is, that even if vxt is not used in the actual build, the
>Makefile.in produced by automake uses g++ to link gnuplot (and I think
>there is no way around this).
What you're saying is that g++ is still used even if you asked for:
./configure --disable-wxwidgets
Right ?
Then it is indeed an automake issue.
Logged In: YES
user_id=1244989
Originator: YES
Exactly, have a look at your Makefile.in.
When automake creates Makefile.in, it knows that gnuplot is built from C-sources and maybe additional C++-sources. At that time automake cannot possibly know whether or not the C++-sources will be used. Of course, in principle automake could create different rules for these two cases. This is, however, not he way automake works; the rule to link gnuplot unconditionally uses g++.
So the only way out is to force automake to create rules for two different binaries -- one with C-only sources and one with additional C++-sorces.
From this point on there are (at least) these two possibilities:
(1) Install one of the binaries as gnuplot
(2) Link (or copy) one of the binaries to gnuplot and install gnuplot
I have chosen (2) for reasons I mentioned earlier today.
Logged In: YES
user_id=1333817
Originator: NO
Ok, I understand. Thanks for the explanation.
Then, I see different options:
* the workaround you've offered,
* or build the wxt terminal as a "convenience library" in src/wxterminal, which would be linked to the core at the final step. The core only has C files, so it would be built with CC, and CXX would be used for the wxt library. One side advantage is that we would have shorter build lines (fewer include flags) for the core files. One side drawback is that 'ar' would be needed, but I guess it's one of the standard GNU utilities coming along with the autotools.
* or do nothing right now if the current situation is bearable and wait for the plugin framework to settle (the latter depends on me, I guess). The drawback of the plugin system is its dependency on libtool, and GLib as it is written currently.
What do you think of this ?
Replacement for earlier patch
Logged In: YES
user_id=1244989
Originator: YES
Hold it.
I found a much better way to do things. All one has to do is to give an explicit rule how to build gnuplot$(EXEEXT) using either CXXLINK or LINK. This prevents automake from generating a rule, this time without warnings.
The attached patch does just this. Except for CXXLINK/LINK the rule is exactly as automake-1.9 would generate. I tested this with automake-1.10 and here the generated rules are slightly different but functionally equivalent.
To be explicit: the automake-1.10 generated rule would not contain gnuplot_LDFLAGS because this would be empty. If gnuplot_LDFLAGS were non-empty the rule would use gnuplot_LINK (or maybe gnuplot_CXXLINK) which would be LINK + gnuplot_LDFLAGS,
thus the effect would be exactly the same.
For a future automake-1.11 who knows?
File Added: gnuplot-4.2.0-patch
In preparation for eventual release of gnuplot version 4.4, existing bugs and patchsets are being re-prioritized.
I have chosen to use the following categories
9 - should be fixed for 4.4.rc1 if possible
7 - should be fixed, but not high priority for 4.4.rc1
5 - default priority for newly submitted tracker items
2 - not important / not under active consideration
These are my personal ratings. If you want to argue for a different priority on one or more bugs - go right ahead.
Ethan Merritt (sfeam)