2013-10-06 2 views
4

На ubuntu-13.04 у меня возникла ошибка при создании исполняемого файла из разделяемых библиотек с использованием GCC-4.7.3, предоставляемого дистрибутивом linux.Линейный компоновщик: '-lpng' ингибирует '-lz'?

Я предполагаю, что проблема между libpng и zlib (первая использует последнее), но я не знаю почему.

Во-первых, моя команда:

$ gfortran -o test_muesli_config_fml test_muesli_config_fml.o -fopenmp 
-Wl,--rpath,/usr/local/lib/muesli /usr/local/lib/muesli/libfml.so -lstdc++ 
-Wl,--rpath,/usr/lib /usr/lib/liblapack.so -Wl,--rpath,/usr/lib /usr/lib/libblas.so 
-lpng -lz -lpthread -lreadline -lhistory 

, который дает следующее сообщение об ошибке:

/usr/local/lib/muesli/libfml.so: undefined reference to `gzwrite' 
/usr/local/lib/muesli/libfml.so: undefined reference to `gzopen' 
/usr/local/lib/muesli/libfml.so: undefined reference to `gzclose' 
/usr/local/lib/muesli/libfml.so: undefined reference to `gzread' 
collect2: error: ld returned 1 exit status 

Но обратите внимание, что -lz присутствует. После этого, я добавил опцию компоновщика --trace-symbol= для того, чтобы получить больше информации:

$ gfortran -o test_muesli_config_fml test_muesli_config_fml.o -fopenmp 
-Wl,--rpath,/usr/local/lib/muesli /usr/local/lib/muesli/libfml.so -lstdc++ 
-Wl,--rpath,/usr/lib /usr/lib/liblapack.so -Wl,--rpath,/usr/lib /usr/lib/libblas.so 
-lpng -lz -lpthread -lreadline -lhistory -Wl,--trace-symbol=gzwrite 

, который в свою очередь, дает результаты:

/usr/local/lib/muesli/libfml.so: reference to gzwrite 
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libz.so: definition of gzwrite 
/usr/local/lib/muesli/libfml.so: undefined reference to `gzwrite' 
/usr/local/lib/muesli/libfml.so: undefined reference to `gzopen' 
/usr/local/lib/muesli/libfml.so: undefined reference to `gzclose' 
/usr/local/lib/muesli/libfml.so: undefined reference to `gzread' 
collect2: error: ld returned 1 exit status 

так, gzwrite находится в libz.so, но компоновщик не делают используй это!

Случайно, я решил удалить опцию -lpng (на самом деле библиотека libpng не используется), и моя проблема решена! Зачем?

Во-вторых, я скомпилирую весь свой код с другой версией GCC-4.7.3 (скомпилированный мною - я использую для тестирования многих версий компилятора), и ошибка не произошла, даже с использованием как -lpng и -lz!

Любая идея?

Кроме того, другая попытка с другой программой (которая USE libpng) ведет к успешной сборке.

редактировали 2013-10-08

Я довольно уверен теперь, что это ошибка в убунту-13,04: Я пробовал два других Linux дистрибутивы (Fedora 16 - Ubuntu-10,04) и поведение компоновщика является стандартным, а не как описано выше в первой части моего сообщения.

Я планирую сообщить об этой проблеме в сообществе ubuntu. С уважением.

редактировали 2013-10-09

Исправлена ​​ошибка сообщается в https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1237270

+0

Что делать, если вы измените порядок -lpng и -lz в командной строке компоновщика?Хотя я думал, что порядок имеет значение только для статических libs ... – Torp

+0

Я уже много пробовал, поскольку множественные вхождения: ничего не дает! – EdouardC

+0

Может ли быть, что (Ubuntu's) libpng определяет эти символы таким образом, что делает их непригодными для дальнейшего разрешения, в результате чего libz игнорируется (символы уже получены), но не позволяют им использовать их? Я знаю, что это звучит как полный сумасшедший разговор, но это то, что я вижу здесь. Я предполагаю, что 'nm' или' objdump' на libpng, и сравнение символов libz с соответствующим libz может пролить свет на это. – rubenvb

ответ

0

Два возможных исправлений (до тех пор, пока убунту не самовосстановлению):

  1. Попробуйте компилируйте в libpng.a и libz.a как статическую библиотеку (это может быть только временное решение, потому что статические библиотеки в большинстве случаев являются злыми).

  2. Перекомпилируйте libpng из исходного источника и скомпилируйте libz.a как статический.

Смежные вопросы