Project

General

Profile

Bug #2897

Default compiler ignores LIBRARY_PATH

Added by enric 12 months ago. Updated 9 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
04/01/2016
Due date:
% Done:

0%


Description

The default compiler of "DragonFly 4.4-RELEASE" ignores the value of the environment variable LIBRARY_PATH.

Steps to reproduce:

cat > foo.c
int foo(void) { return 42; }
^D

cat > main.c
int foo(void);
int main() { return foo(); }
^D

# commands to reproduce the problem:
cc -c foo.c
ar r libfoo.a foo.o
LIBRARY_PATH=`pwd` cc main.c -lfoo

# observed behaviour: the compiler gives an error because it cannot find foo

# expected behaviour: the compiler produces a program a.out that returns 42

# workaround:
cc main.c -lfoo -L`pwd`

This causes problems when compiling some packages that work correctly in other
systems, notably OpenBSD and Debian linux. This problem is easy to workaround
(once you identify it!). However, the behavior is inconsistent with the provided
documentation.

Quote from cc(1):

LIBRARY_PATH
The value of LIBRARY_PATH is a colon-separated list of directories,
much like PATH. When configured as a native compiler, GCC tries
the directories thus specified when searching for special linker
files, if it can't find them using GCC_EXEC_PREFIX. Linking using
GCC also uses these directories when searching for ordinary
libraries for the -l option (but directories specified with -L come
first).

Either the documentation or the compiler specs should be updated to be
consistent.

By running the compiler with the "-v" option, you can see that the variable is
acknowledged, however its values are not passed to the linker.

History

#1 Updated by dragonflybsd1 9 months ago

if anything, LD_LIBRARY_PATH would be used, but neither are good practice.

The resolution to this would be to remove mention of LIBRARY_PATH from cc(1) as suggested.

Also available in: Atom PDF