1

GCC (linking) was barfing that it could not find a library when specified with an absolute path. Note the reason I want this is I have a build system that keeps all libraries resolved by absolute path so it can keep an ordered set of unique entries.

g++ (...) -l/path/to/library.so

I saw a bug report where some people thought it was a bug, and others thought the fact it ever worked was a bug, and it was fixed.

There was some discussion that one had to precede the path with a ':'

Anyway didn't make it work.

So to test in the build system I put code in to truncate the absolute library path if it's "prefix" matched any of the library paths specified to GCC and truncate the absolute library path.

g++ (...) -L/path/to -llibrary.so

This worked.
I also tried this.

g++ (...) -L/path/to -l/path/to/library.so

and it worked. 9 (though investigating .. looks like this was an error in the build script )

It seems possibly if any of the search paths specified for GCC are a "prefix" to a library specified with an absolute path it finds the library. I would also assume it takes the first hit in the ordered list of library paths supplied.

So my questions.

  • Is this supported behavior?
  • Is it better in this to truncate the absolute library path in the build script or pass in the absolute path.

I notices some related issues brought up here:

How to link using GCC without -l nor hardcoding path for a library that does not follow the libNAME.so naming convention?

This indicates a "non searched" full path is "burned in" to an executable thus overriding any runtime library path when it is executed? Is this correct ? If so it means specifying the library with the full path on the command line is not appropriate. On deployment the built app and associated libraries would be installed in standard searchable locations.

peterk
  • 5,136
  • 6
  • 33
  • 47

2 Answers2

2

I would say in this case don't use -l, just pass the full library path as part of the command: gcc (other options) /path/to/library.so

SoronelHaetir
  • 14,104
  • 1
  • 12
  • 23
  • meaning it will determine it is a library by looking at the suffix ? – peterk Dec 27 '17 at 18:42
  • @peterk: No, Unix usually doesn't work with file suffices. It will determine it is a library by looking at the structure of the file. – Martin Bonner supports Monica Dec 27 '17 at 18:43
  • @MartinBonner Wouldn't GCC lookup the corresponding stub `.a` file automatically in turn? – user0042 Dec 27 '17 at 18:50
  • @user0042 I don't think there is a stub .a file. It's not like .dll/.lib on Windows. – Martin Bonner supports Monica Dec 27 '17 at 20:52
  • passing an absolute path without the leading -l works fine. BUT the files must have it's included "lib" prefix and "a" or "so" suffix. I was unable to find any documented difference in the behavior of "-lpath" and just the path for absolute paths unless it is simply that -l does not take absolute paths and ignore the library search path in that case but this is not stated in the man page. – peterk Dec 28 '17 at 01:21
0

Note: this is with gcc (Raspbian 4.9.2-10) 4.9.2 I'm getting a library set built for it.

Ok - much banging on it and testing different cases

Using the full path as an argument to GCC apparently burns in hard coded absolute path to the library which is used at run time to resolve where it is. This is not desired as the app is intended to be deployed with searchable shared libraries that might end up in different places.

-llibmyLib.so   does not work with a search path. 
-lmyLib         does work with a search path 
     ( with lib prefix and suffix removed - apparently 
       it tries all available suffi and prepends "lib" for it's 
       search by default )

-

-l:libmyLib.so   DOES work with a search path, 
               as ':' specifies the file name is not to be altered.

-l:debug/libmyLib.so DOES work ( a  subdir under the search path )
-l:release/libmyLib.so DOES work ( a subdir under the search path )

With this info - (apparently) knowing what it does I can now move forward !!

peterk
  • 5,136
  • 6
  • 33
  • 47