При сборке тестового примера с O1 падает на x86_64: gcc -O1 -ldl -Wall test-o2-x86_64.c -o test-o2-x86_64 ./test-o2-x86_64 dlvsym(open64): 0x2aaaaad70100 dlsym(open64): 0x2aaaaad70100 Segmentation fault и не падает при использовании O0: gcc -O0 -ldl -Wall test-o2-x86_64.c -o test-o2-x86_64 ./test-o2-x86_64 dlvsym(open64): 0x2aaaaad70100 dlsym(open64): 0x2aaaaad70100
Created attachment 1353 [details] test-o2-x86_64.c Тестовый код.
Нет, это не ошибка в gcc, это либо ошибка в glibc либо неправильное использование open64.
Created attachment 1355 [details] dltest.c Новый тест на dlsym.
$ gcc -Wall -W -Werror -O2 dltest.c -ldl -o dltest $ ./dltest open dlsym(open) = 0x2aaaaad70070 $ ./dltest open64 dlsym(open64) = 0x2aaaaad70100 Segmentation fault $ ./dltest exit dlsym(exit) = 0x2aaaaacf5c70 $ Замечу, что 1. на x86_64 нет системного вызова open64, только простой open. 2. на x86_64 cat использует библиотечную функцию open, в то время как на ix86 - open64: 32$ ltrace cat /dev/null 2>&1 |fgrep open open64("/dev/null", 0, 027777773360) = 3 64$ ltrace cat /dev/null 2>&1 |fgrep open open("/dev/null", 0, 037777765230) = 3
так всё-таки, как быть ? можно конечно использовать open вместо open64 на x86_64, но что интересно: на других вызовах это не проявляется (lstat64 работает) в debian'овском переписанном fakechroot используется open64 (собирается по умолчанию без оптимизации).
сегодня нарвались на: http://lists.gnu.org/archive/html/guile-devel/2006-02/msg00071.html guile18 становится действительно очень нестабильным будучи собранным с оптимизацией > 0. Дима, нам похоже нужен gcc4 , если мы хотим дистрибутив для amd64.
Новый компилятор быстро не собирается...
Мой тест новый компилятор прошёл.
