how to provide extra dynamic libraries via cmdline?

[umlaeute]

if i have an external that needs to (dynamically) link against libfoo, i can specify this dependency by adding a line:

ldlibs=-lfoo

However, it seems to be impossible to add libraries during the build process.
I would have expected the build-system to honour the LDLIBS variable, but it seems to be ignored (unlike CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS)

$ make LDLIBS=-lfoo
[...]
cc -rdynamic -shared -fPIC -Wl,-rpath,"\$ORIGIN",--enable-new-dtags -o xxx.pd_linux xxx.o  -lc -lm   

(Right now, my main motivation for this is to be able to fix broken 3rd party buildsystems, but there might be more mainstream use-cases as well).

[katjav]

Indeed LDLIBS is currently not implemented. Lib options passed to the linker are specified in three variables:

• c.ldlibs / cxx.ldlibs (in pdlibbuilder platform-specific sections)
• ldlibs (optionally specified in lib makefile)
• <class>.ldlibs (optionally specified in lib makefile)

If we implement LDLIBS as an addition to those other categories, will that be helpful for your use case or should it override some?

[umlaeute]

I was thinking of just appending the LDLIBS to the existints ...ldlibs.
overriding some might just cause confusion (as opposed to override all).

However, I don't seem to be able anything much to support appending (or replacing).

• autotools (which doesn't support LDLIBS at all, but uses LIBS instead) will simply replace the flags (so the user who wants to use that var, has to provide all the libraries manually)
• i thought that i read that GNU Make would use LDLIBS for extra libraries (thus implying appending), but cannot find anything like that anymore, and the manual simply talks about "Library flags or names" which might be read as the authorative list of libraries (that is: replacing libraries from other sources)

So while my use-case at hand would suggest appending LDLIBS to the existing libraries, it seems that the more common expactation is to replace the existing libs...which somewhat makes sense, as it's hard to imagine a use case (for non-broken Makefiles) where one would specify additional libraries (which are never called into).

[katjav]

Variables CFLAGS and LDFLAGS selectively override options 'that are not strictly required' (i.e. optimizations as predefined by pdlibbuilder) and leave other makefile-defined options untouched (which are considered indispensable). Specifically, CFLAGS and LDFLAGS do not override lib makefile variables cflags, ldflags and <class>.ldflags. Unfortunately a similar logic could not be applied for LDLIBS.

In the case of a lib makefile with broken definition of cflags you'd need to override it literally in the make command line. That would be the same for libs:

$ make ldlibs=-lfoo

[umlaeute]

but make ldlibs=-lfoo doesn't override <class>.class.ldlibs; and c.ldlibs resp. cxx.ldlibs are kept as well (or not, i'm not entirely sure what is goind on).

It seems that to completely override all the build-system's libraries, you'd need something like:

make helloworld.class.ldlibs= c.ldlibs= cxx.ldlibs= ldlibs=

This is probably OK, but should be documented. (The biggest issue I'm having is that in order to completely override the build-flags, you'd need to know each class that is being built.)

So (by now) I guess it would still be nice to be able to override all libraries (for all classes) with a simple LDLIBS.

[katjav]

When not defined in a lib makefile, variables ldlibs and <class>.ldlibs should be empty. Defining ldlibs (in the lib makefile or make command line) should pass it for each class as an addition to c.ldlibs and cxx.ldlibs (which are predefined with platform-specific options for all pd libs). Check if this works as intended with:

$ make vars ldlibs=-lfoo

If not, we have a bug (but it seems to work all right). When a lib makefile does specify <class>.ldlibs, isn't it reasonable to override this variable explicitly in a make command line?

Frankly, I agree that it would be better for consistency to have conventional variables like CFLAGS, LDFLAGS, LDLIBS etc. literally in the recipe lines so you can override all options with names that you expect. That would be easier if pdlibbuilder didn't accept things like two languages and class-specific link options.

[katjav]

In addition to the previous comment: if you want to completely override the build system's libs, overriding c.ldlibs should do, unless:

1. the library (also) includes C++ code
2. the library makefile defines <classname>.class.ldlibs

If not for these cases, we could use LDLIBS unambiguously within the recipe, combining variables from Makefile.pdlibbuilder and library makefile. But in the current implementation of the recipes, c.ldlibs or cxx.ldlibs and <classname>.class.ldlibs are evaluated conditionally depending on language of the corresponding source file(s) and class name. These target-specific conditions cannot be tested before the corresponding rule begins, and on the other hand I don't see a way to define LDLIBS within the recipe. But I am not a GNU make expert, maybe I'm overlooking possibilities.

[katjav]

For the record, in this SO topic a method to support adding values from command line to makefile variables is explained:

https://stackoverflow.com/questions/2129391/append-to-gnu-make-variables-via-command-line

The simple idea is to define the variable with '+=' rather than '=' or ':='. Then if the variable is defined in the environment, the makefile definition will be added to it. I tried it with setting in a makefile that includes pdlibbuilder:

test += one

and then on command line:

$ test=two make vars

In the output it shows as:

variable test = two one

So the environment definition comes first in the list, which I didn't expect but is logical after all.

@umlaeute, I don't know if your original question as in the issue title is still relevant. In any case this is a nice trick to remember when we have a need for it.

[umlaeute]

the thing is: sometimes we want to add to the flags (+=), and sometimes we want to replace flags (=).

if we can only have one of the two, i'd favor the second (because you can reconstruct the original flags, and then pass them via cmdline flags; but you cannot take away breaking flags if you can only add).

what's more: sometimes you want add on the left-side (prepending), and sometimes on the right-side (appending)..

i don't know whether it's worth to support both.

[katjav]

If a variable is defined with '+=' in the makefile it is still possible to override with a make command argument, as verified by defining in the makefile (like before):

test += one

and then command:

$ make allvars test=two

will give this line in the output:

variable (command line) test = two

For comparision here with the environment definition (before calling make):

$ test=two make allvars

which gives in the output:

variable (file) test = two one

It looks as if only the file is considered to be the origin of the definition but that is possibly a side effect of make's sort function.

Anyhow, the fact remains that the environment definition always comes first and the file definition second.