./configure --with-plplot does not work properly

[Jari Häkkinen]

Using the --with-plplot option does not trigger the use of the specified plplot libs. The detection of apr will set the -L path to system directories in my machine and I have a copy of plplot there but I'd like to use a user specified plplot.

[Peter Johansson]

If I understand you correctly the configure and detection of plplot works fine. But the problem is that, if you for example issue ./configure --with-plplot=/path/to/plplot, you will get

AM_LDFLAGS="-L/opt/local/lib -L/path/to/plplot/lib"

where the first part is for apr and the second part is for plplot. Now the problem is that you have another plplot in /opt/local/lib and the linker uses the first it finds.

I suppose what you want is that the linker command contains -L/path/to/plplot before -L/opt/local/lib. That seems easy perhaps but if we just change order of them you would get the symmmetrical problem when you have apr installed in /path/to/plplot (which you don't wanna use).

I noticed that the automake generated linker command contains

$(AM_LDFLAGS) $(LDFLAGS)

so if we could move -L/opt/local/lib from AM_LDFLAGS to LDFLAGS. I wonder if if we set LDFLAGS=-L/opt/local/lib does configure still set AM_LDFLAGS=/opt/local/lib; otherwise that could be a workaround that you issue

./configure --with-plplot=/path/to/plplot LDFLAGS=/opt/local/lib

Did I understand the problem correctly?

[Peter Johansson]

Replying to peter:

 ./configure --with-plplot=/path/to/plplot LDFLAGS=/opt/local/lib

I tried this and it results with having -L/opt/local/lib in both AM_LDFLAGS and LDFLAGS. I think we should change that so items in LDFLAGS never occur in AM_LDFLAGS.

[Jari Häkkinen]

Replying to peter:

Did I understand the problem correctly?

Yes, and I realize the symmetrical problem. Maybe there is a way of getting pkg-config to report absolute paths?

Other packages I have tried can resolve the issue, or at least it has worked for me. When I have had several different versions of support libraries the --with-package option has worked but I cannot remember if I had any of the packages installed in default directories or not. Also the previous successes may have been purely coincidental.

[Peter Johansson]

Replying to jari:

Yes, and I realize the symmetrical problem. Maybe there is a way of getting pkg-config to report absolute paths?

Not as far as I understand. Nevertheless, it seems like an ugly solution; not to mention that library file names are system dependent.

Other packages I have tried can resolve the issue,

Which packages? I've tried to find examples out there but could not find packages with this issue because either they only have one --with-foo or the they do not use it to set (AM_)LDFLAGS (but only turn off support, --without-foo).

[Peter Johansson]

Replying to peter:

I tried this and it results with having -L/opt/local/lib in both AM_LDFLAGS and LDFLAGS. I think we should change that so items in LDFLAGS never occur in AM_LDFLAGS.

I have a patch fixing this for LDFLAGS, CPPFLAGS, and CXXFLAGS. Should I commit it in trunk or 0.8-branch?

[Jari Häkkinen]

Replying to peter:

Which packages? I've tried to find examples out there but could not find packages with this issue because either they only have one --with-foo or the they do not use it to set (AM_)LDFLAGS (but only turn off support, --without-foo).

I now I used --with-foo in flightgear but the build system there is a mess and should not be used as an example. Otherwise I have no immediate example.

[Jari Häkkinen]

Replying to peter:

I have a patch fixing this for LDFLAGS, CPPFLAGS, and CXXFLAGS. Should I commit it in trunk or 0.8-branch?

Put it into 0.8-branch.

[Jari Häkkinen]

Thinking on this problem, shouldn't this issue be resolved by the linker? One should be able to set the -L search path during compile. The search path should be there always but giving -L's should change the search path:

ld -L/usr/local/lib -lfoo -lbar -L/path/to/plplot -lplplot -L/path/to/apr -lapr

should change the search path and add the plplot lib path first when searching for -lplplot and tben change the order when looking for apr. Then configure could be set to create smarter option order for the linker.

[Peter Johansson]

(In [1159]) refs #467. Change how CPPFLAGS, CXXFLAGS and LDFLAGS are picked up automagically in configure. First, save flag given by user. Second add flags to e.g. LDFLAGS (based on --with-plplot etc) but add only values not already in LDFLAGS. Third, calculate difference SVNDIGEST_LDFLAGS

LDFLAGS - LDFLAGS_init and restore LDFLAGS to LDFLAGS_init (given by

user). This implies we avoid multiple identical entries. For example, before the linker could get 3 copies of '-L/opt/local/lib' because it got one from APR_LDFLAGS, one from SVN_LDFLAGS, and one from PLPLOT_LDFLAGS. It also means that if user gives ./configure -L/foo -L/bar, configure will not add these paths into SVNDIGEST_LDFLAGS and hence the user is in power of deciding the path order for the linker/compiler.

[Peter Johansson]

Replying to jari:

Yes, and I realize the symmetrical problem. Maybe there is a way of getting pkg-config to report absolute paths?

I suspect plplot has no .la file, but generally speaking absolute path might be an idea when dealing with .la files. The assumes we use libtool, of course.

[Jari Häkkinen]

(In [1173]) Addresses #467. I need this order of LDFLAGS to get autogeneration of reports.

[Peter Johansson]

Replying to jari:

Thinking on this problem, shouldn't this issue be resolved by the linker? One should be able to set the -L search path during compile. The search path should be there always but giving -L's should change the search path:

ld -L/usr/local/lib -lfoo -lbar -L/path/to/plplot -lplplot -L/path/to/apr -lapr

should change the search path and add the plplot lib path first when searching for -lplplot and tben change the order when looking for apr. Then configure could be set to create smarter option order for the linker.

For the record, I bumped into this sentence: "-l options benefit only from the -L options listed before it." in ​gnulib's lib-link.m4