DLPATH and make

[videlec]

Compiling Sage with archlinux we are faced to a delicate problem:

• make is linked to libguile (that link to libgc)
• libgc is packaged by Sage with a different version and put in $SAGE_ROOT/local/lib
  As a consequence, modifying LD_LIBRARY_PATH causes build failure (see [https://trac.sagemath.org/ticket/24575 upstream issue]). For flint, the culprit are the lines 1-5 of Makefile.in

ifdef $(DLPATH)
  $(DLPATH):=$($(DLPATH)):$(DLPATH_ADD)
else
  $(DLPATH):=$(DLPATH_ADD)
endif

Removing them allow to build flint without troubles.

Note that we have a possible workaround in Sage using LD_PRELOAD (see the branch on upstream ticket).

[videlec]

see also arb issue 213

[wbhart]

Someone has added this patch to set DLPATH for some reason. It doesn't seem that Flint itself actually uses it anywhere in the Makefile. So I'd need to understand why it was added before I could just remove it. Reverting someone else's fix isn't good practice in general. I have no problem with changing it, but I need to understand what problem it was originally fixing.

[wbhart]

JP Flori made the changes by the way. But it was just done as part of an overhaul of the build system five years ago. So the real question is, why should DLPATH ever be set. What is it actually for, and why should it be set? Google doesn't seem to bring up any useful information on it.

[videlec]

DLPATH is actually LD_LIBRARY_PATH (the change is visible in Makefile and not in Makefile.in).

DLPATH=LD_LIBRARY_PATH
DLPATH_ADD=$(CURDIR):/usr/local/lib:/usr/local/lib

ifdef $(DLPATH)
  $(DLPATH):=$($(DLPATH)):$(DLPATH_ADD)
else
  $(DLPATH):=$(DLPATH_ADD)
endif

[wbhart]

But if that is the case and I delete those lines, then surely make check won't work any more, since the library location won't be added to LD_LIBRARY_PATH.

[videlec]

Indeed. Would that be ok to set LD_LIBRARY_PATH only in the check part?

Concerning Sage, we are installing before testing with "make check". In such situation we could still use the workaround

make check DLPATH_ADD=

[wbhart]

I think that is the only reason it is set, so yes, it should be fine to set it only in the check part. Unfortunately I don't know how to do this. I don't know if you can stick an export directive inside a target like make check. The order in which make files are processed is frankly a mystery to me.

[wbhart]

Yeah, I don't think that is possible. Make doesn't specify an order of operation. A makefile consists of a bunch of targets and a bunch of variables, from what I can tell. The export directive just exports all the variables. It's not like a program that you get to direct with control flow.

At least there's no mention of anything like that in the documentation [1].

[1] https://www.lix.polytechnique.fr/~liberti/public/computing/prog/make.html

[videlec]

https://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html

[wbhart]

But LD_LIBRARY_PATH is not just a variable here, it is exported to the environment. It's export that you need to be conditional, not the variable.

[wbhart]

Ok, but maybe they thought of that. We just set LD_LIBRARY_PATH to the modified value for make check, and then the export directive perhaps only exports that value if check is the current target.

The problem might be that check needs to build the library. So I'm not sure if it will manage that correctly or not.

My bet would be that it does not reexport if one target depends on another. Only the variables that belong to the user selected target are exported, I would guess.

[isuruf]

I think LD_LIBRARY_PATH and friends should be removed in favour of rpath. See my comment at #321 (comment)

[wbhart]

I guess that would work, since the test binaries are only intended to work in the source tree.

[wbhart]

Yeah, it looks like the RPATH option would fix a number of problems at once. So let's do it that way.