ld и LD_LIBRARY_PATH

точнее Почему ключ -L<some dir> не заменяет LD_LIBRARY_PATH

а какая вообще связь между ld и LD_LIBRARY_PATH?

hint: никакой...

// wbr

> а какая вообще связь между ld и LD_LIBRARY_PATH?

> hint: никакой...

man ld | grep LD_LIBRARY_PATH не полностью с этим соглашается

в общем такая петрушка

g++ -o ../lib/test test.o -L../lib -lsub1 -lsub2

ls ../lib
libsub1.so
libsub2.so

в этом случае получается куча unresolved externals

export LD_LIBRARY_PATH=../lib
и те де самые параметры прокатывают и все собираеся

Но это криво, я так считаю :)

> man ld | grep LD_LIBRARY_PATH не полностью с этим соглашается

впрочем, это правильное замечание поступило с галерки:

-rpath-link DIR
When using ELF or SunOS, one shared library may require another. This happens
when an "ld -shared" link includes a shared library as one of the input files.

When the linker encounters such a dependency when doing a non-shared, non-relo-
catable link, it will automatically try to locate the required shared library
and include it in the link, if it is not included explicitly. In such a case,
the -rpath-link option specifies the first set of directories to search. The
-rpath-link option may specify a sequence of directory names either by specify-
ing a list of names separated by colons, or by appearing multiple times.

This option should be used with caution as it overrides the search path that may
have been hard compiled into a shared library. In such a case it is possible to
use unintentionally a different search path than the runtime linker would do.

The linker uses the following search paths to locate required shared libraries:

1. Any directories specified by -rpath-link options.

2. Any directories specified by -rpath options. The difference between -rpath
and -rpath-link is that directories specified by -rpath options are included
in the executable and used at runtime, whereas the -rpath-link option is
only effective at link time. Searching -rpath in this way is only supported
by native linkers and cross linkers which have been configured with the
--with-sysroot option.

3. On an ELF system, if the -rpath and "rpath-link" options were not used,
search the contents of the environment variable "LD_RUN_PATH". It is for the
native linker only.

4. On SunOS, if the -rpath option was not used, search any directories speci-
fied using -L options.

5. For a native linker, the contents of the environment variable
"LD_LIBRARY_PATH".

6. For a native ELF linker, the directories in "DT_RUNPATH" or "DT_RPATH" of a
shared library are searched for shared libraries needed by it. The
"DT_RPATH" entries are ignored if "DT_RUNPATH" entries exist.

7. The default directories, normally /lib and /usr/lib.

8. For a native linker on an ELF system, if the file /etc/ld.so.conf exists,
the list of directories found in that file.

If the required shared library is not found, the linker will issue a warning and
continue with the link.

таким образом, остаётся дождаться от автора темы теста, который бы опровергал указанное поведение.

// wbr

Как тебе уже сказали проблема вероятно в том, что либы связаны между собой, и для нахождения либ по именам применяется LD_LIBRARY_PATH и т.д.

Чтобы обходиться без него можно указать RPATH, т.е. в момент линковки либ и прочих бинарников указывать где следует искать либы к ним. например:

LDFLAGS += -Wl,--rpath,\$$ORIGIN - говорит искать либы в том же каталоге где и бинарник(runtime поиск при загрузке).

LDFLAGS += -Wl,--rpath,\$$ORIGIN/../lib - в подкаталоге lib каталога уровнем выше и т.д.

Проверять с помощью objdump -p, должна появиться строка вида

RPATH $ORIGIN

все верно, -rpath решил проблему.

Всем спасибо

Прошу прощения за оффтопик, но может кто знает как то же самое сделать под дарвином ? LD_LIBRARY_PATH не помогает. В чем то в другом дело.