Makefile may use incorrect versions of the libraries

[tamas]

Currently one can specify separate directories for the various libraries during the configuration. For example we can specify --with-geos=/home/szekerest/usr/bin/geos-config

But when using some of the libraries from the default location it may affect how the libararies are used during the make.

For example GD may bring in the following values in the Makefile GD_LIB= -lgd -L/usr/local/lib -lgd -ljpeg -lfreetype -lpng -lz

So -L/usr/local/lib will be added to the linker command line at the beginnings so mapserver will link against the geos lib installed in /usr/local/lib instead of /home/szekerest/usr/lib.

[dmorissette]

Um... I have verified that the -L paths are indeed searched in the order in which they appear, so you are right that if GD inserts -L/usr/local/lib at the beginning of the command line and GEOS adds -L/home/szekerest/usr/lib later we will end up linking with the copy of GEOS in /usr/local/lib if there is one there.

What do you propose as a solution? Is there another way to specify library search paths that we should be using? If not then the only solution is to not install copies of libs in multiple places the way you described here.

[tamas]

It would be enough to insert the directories of the default locations to the end the linker command like. Perhaps we should introduce a new variable DEFAULT_LIBS to collect those paths and append that to the end of SUP_LIBS if it is possible.

[dmorissette]

Tamas, I'm not sure if/how we can determine what is a "default location" (DEFAULT_LIBS) and what is not (SUP_LIBS). /usr/local is a well-known location, but for instance one could use /opt/local/lib or any other path for local libs installation and we have no way to tell if this should go in DEFAULT_LIBS or SUP_LIBS.

And anyway, even if we had a way to determine that, many of the -L paths come from '*-config --libs' scripts so we'd have to parse the -L out of the script outpout and move it to those variables... could be quite messy.

Moving to 5.4 release milestone. If you can provide a patch to solve this then I'll look at including it, otherwise I'd be tempted to close as WorksForMe since the case you want to support seems quite unusual.

[dmorissette]

Closing as WONTFIX since I don't see a clean solution to this other than not installing multiple copies of the same libs on the system in cases like the one you describe. Feel free to reopen if you have a fix or patch to propose.