Linking against a lib.(a|so) generated by an action target

[Salman Malik]

Hi,

I am trying to link against a library in third party that is compiled and .a|.so generated with an action target (this library was using a meson build system so I created an action script to generate the lib).

I got it to work by providing `lib_dirs` that point to the path where the library is put after compilation and then using `libs` directive to tell GN to link against the library name.

The problem with this approach is that when I specify `lib_dirs`, another library that was already being linked with the target stops working i.e. symbol lookups for this existing/previously used library stops working.

Again, I got this to work by adding another entry in `lib_dirs` pointing to the path where this system library is installed but this seems fragile since this system library might be installed in a different path in a different arch/setup.

(Aside: Specifying `lib_dirs` causing other libs to break seems like a bug in GN?).

What is the recommended way of linking against a generated third party lib?

Appreciate the guidance here.

PS: Another related bug I filed while working on this: https://bugs.chromium.org/p/chromium/issues/detail?id=1422716 (It has pointer to the CL as well in case someone is interested in looking at the code)

Thanks,

Salman

[Brett Wilson]

I haven't done this myself, but you might try to just put the full path to the library in the "libs" variable and not set lib_dirs. There is some special handling (see "gn help libs") for libs that have a slash in them, so this may work.

Brett 

[Salman Malik]

Thanks, Brett! I did exactly that but ran into the reported issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1422716 where the target action (that has been placed in public deps) is probably getting executed after the attempt to locate the path in "libs".

Salman

[Brett Wilson]

I followed up on the bug.