При сборке rust-кода с этой библиотекой не получается найти заголовки. pkg-config не возвращает -I/usr/include. далее https://crates.io/crates/pkg-config не включает /usr/include в include_paths далее onig_sys не может найти oniguruma.h там такой код: // onig_sys/build.rs:240-245 for path in &lib.include_paths { let header = path.join("oniguruma.h"); if header.exists() { bindgen_headers(&header.display().to_string()); return; } } Мне кажется, у нас дефолтные пути специально убраны. Но тогда ещё было rust :) На ALT: $ cat /usr/lib64/pkgconfig/oniguruma.pc prefix=/usr exec_prefix=/usr libdir=/usr/lib64 includedir=/usr/include datarootdir=/usr/share datadir=/usr/share Name: oniguruma Description: Regular expression library Version: 6.9.10 Requires: Libs: -lonig Cflags: На Fedora: $ cat /usr/lib64/pkgconfig/oniguruma.pc prefix=/usr exec_prefix=/usr libdir=/usr/lib64 includedir=/usr/include datarootdir=/usr/share datadir=/usr/share Name: oniguruma Description: Regular expression library Version: 6.9.10 Requires: Libs: -L${libdir} -lonig Cflags: -I${includedir}
Вижу что в pc.in есть желаемое, а в итоговом результате - нету. Но у меня в пакете нет ничего специального для того, что бы чистить pc файлы. Думаю что виноват кто-то в rpmbuild: Cleaning files in /usr/src/tmp/oniguruma-buildroot (auto) mode of './usr/lib64/libonig.so.5.5.0' changed from 0755 (rwxr-xr-x) to 0644 (rw-r--r--) Verifying and fixing files in /usr/src/tmp/oniguruma-buildroot (binconfig,pkgconfig,libtool,desktop,gnuconfig) /usr/bin/onig-config: 61c61 < show_includedir=-I/usr/include --- > show_includedir= /usr/lib64/pkgconfig/oniguruma.pc: Cflags: '-I${includedir}' --> '' /usr/lib64/pkgconfig/oniguruma.pc: Libs: '-L${libdir} -lonig' --> '-lonig' Checking contents of files in /usr/src/tmp/oniguruma-buildroot/ (default) $ rpm -qf /usr/lib/rpm/fixup-pkgconfig rpm-build-4.0.4.210-alt1.x86_64
Т.к. проблема видимо глобальная, то локальные хаки глобально ничего не изменят - чинить надо rpm-build или rust-код.
-I/usr/include не нужен и даже вреден. Далее следует цитата из man gcc: You can use -I to override a system header file, substituting your own version, since these directories are searched before the standard system header file directories. However, you should not use this option to add directories that contain vendor-supplied system header files; use -isystem for that.
Дим, а насколько вообще реально то, что (при условии что все другие дистрибутивы не вычищают pc файлы) смена порядка поиска заголовков может привести к проблемам ? Ведь чистка pc файлов рассчитана на то, что их будет использовать только gcc, а реальность оказалась такова, что есть и другие потребители и они совсем не готовы к тому, что у нас поведение меняется от апстримного.
(Ответ для Anton Farygin на комментарий #1) > Вижу что в pc.in есть желаемое, а в итоговом результате - нету. > Но у меня в пакете нет ничего специального для того, что бы чистить pc > файлы. Думаю что виноват кто-то в rpmbuild: ... У меня наоборот, не убраны, хотя хотелось бы: $ cat /usr/lib64/pkgconfig/tdjson.pc prefix=/usr Name: tdjson Description: Telegram Library - JSON interface (shared) Version: 1.8.52 CFlags: -I"${prefix}/include" Libs: -L"${prefix}/lib64" -ltdjson Requires.private: tdjson_private Видимо, потому что не использованы промежуточные переменные типа libdir=/usr/lib64 includedir=/usr/include
При каких условиях pkg-config не возвращает -I/usr/include, а должен? Если ошибка в pkg-config-rs, то, вроде бы, он и должен её фиксить. Зачем у нас удаляется -I/usr/include из *.pc файлов не вполне понятно, ведь это ломает поддержку PKG_CONFIG_SYSROOT_DIR / PKG_CONFIG_SYSTEM_INCLUDE_PATH. pkg-config сам справляется с удалением -I/usr/include, но может раньше он этого не делал? Тогда это просто устарело, зачем делать за pkg-config его работу.
Код, который удаляет -I от 2002. Может его убрать? Или оставить только кейс с /usr/local/include new_val=`printf %s "$new_val" |sed -e 's,\(^\| \+\)-I/usr\(/local\)\?/include\($\| \+\),\1\3,g'` || return 1 new_val=`printf %s "$new_val" |sed -e 's,\(^\| \+\)-I\${includedir}\($\| \+\),\1\2,g'` || return 1 хотя, лучше и его убрать, так как заменять просто не нужно, а паковать в /usr/local запрещено. И оставить замену для -Wl,-rpath убрав -L new_val=`printf %s "$new_val" |sed -e 's#\(^\| \+\)\(-L\|-Wl,-rpath,\)/usr\(/local\)\?/'"$RPM_LIB"'\($\| \+\)#\1\4#g'` && new_val=`printf %s "$new_val" |sed -e 's#\(^\| \+\)\(-L\|-Wl,-rpath,\)\('$RPM_BUILD_ROOT'\|'$RPM_BUILD_DIR'\|/usr/lib[^/]*/gcc-lib\)[^ ]*\($\| \+\)#\1\4#g'` || new_val=`printf %s "$new_val" |sed -e 's#\(^\| \+\)\(-L\|-Wl,-rpath,\)\${libdir}\($\| \+\)#\1\3#g'` || return 1 @ldv? На мой взгляд, при обычном и правильном использовании pkg-config ничего не должно поменяться. Наладится использование PKG_CONFIG_SYSROOT_DIR / PKG_CONFIG_SYSTEM_INCLUDE_PATH (хотя очевидно, что никто этим не пользовался). Что-то поменяется если кто-то парсит *.pc files.
Вот тестовое/rfc задание https://git.altlinux.org/tasks/410162/
