Почему-то только мы и uCLibc провайдим strlcpy в /usr/include/string.h, есть ли объяснение этому курьезу? В настроящий момент это ломает сборку компонентов ядра с включенным CONFIG_HAVE_STACK_VALIDATION, который бывает очень полезен: HOSTLD scripts/mod/modpost CC /usr/src/RPM/BUILD/kernel-image-lks-wks-4.6.0-alt0.1/kernel-source-4.6/tools/objtool/libstring.o HOSTLD arch/x86/tools/relocs In file included from ../lib/string.c:18:0: /usr/src/RPM/BUILD/kernel-image-lks-wks-4.6.0-alt0.1/kernel-source-4.6/tools/include/linux/string.h:12:15: error: redundant redeclaration of 'strlcpy' [-Werror=redundant-decls] extern size_t strlcpy(char *dest, const char *src, size_t size); ^ In file included from ../lib/string.c:16:0: /usr/include/string.h:571:15: note: previous declaration of 'strlcpy' was here extern size_t strlcpy (char *__dst, __const char *__src, size_t __n) ^ cc1: all warnings being treated as errors В настоящий момент в ядре уже есть затычка для uCLibc: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a83d869f300bf91df07443b5272db7a5a8eb18b7 Не хочется плодить сущности без надобности, но разве мы уже тоже стали собираться из uCLibc, и если это так, то почему не провайдим нужный define? Вывод на машине с Fedora: $ fgrep -r strlcpy /usr/include/ /usr/include/python3.4m/pyconfig-64.h:/* Define to 1 if you have the `strlcpy' function. */ $ Вывод на машине с ALTLinux: $ fgrep -r strlcpy /usr/include/|fgrep string /usr/include/string.h:extern size_t strlcpy (char *__dst, __const char *__src, size_t __n) $ $ rpm -q glibc-devel glibc-devel-2.23-alt2
(In reply to comment #0) > Почему-то только мы и uCLibc провайдим strlcpy в /usr/include/string.h, есть ли > объяснение этому курьезу? У нас оно под __USE_MISC, который включают _DEFAULT_SOURCE/_GNU_SOURCE/_BSD_SOURCE. Я все-таки надеюсь, что strlcat и strlcpy раньше или позже будут в glibc: https://sourceware.org/ml/libc-alpha/2016-01/msg00205.html Там оно тоже под __USE_MISC. Так что мне кажется, что правильнее всего было бы исправить tools/include/linux/string.h
(In reply to comment #1) > (In reply to comment #0) > > Почему-то только мы и uCLibc провайдим strlcpy в /usr/include/string.h, есть ли > > объяснение этому курьезу? > > У нас оно под __USE_MISC, который включают > _DEFAULT_SOURCE/_GNU_SOURCE/_BSD_SOURCE. > > Я все-таки надеюсь, что strlcat и strlcpy раньше или позже будут в glibc: > https://sourceware.org/ml/libc-alpha/2016-01/msg00205.html > > Там оно тоже под __USE_MISC. > > Так что мне кажется, что правильнее всего было бы исправить > tools/include/linux/string.h А как мы можем исправить tools/include/linux/string.h, если, например в Fedora нет этой функции в принципе? Т.е. апстрим в лице kernel.org это вряд ли примет, пока эта функция не появится там официально. Или речь идет о локальной правке?
(In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > Почему-то только мы и uCLibc провайдим strlcpy в /usr/include/string.h, есть ли > > > объяснение этому курьезу? > > > > У нас оно под __USE_MISC, который включают > > _DEFAULT_SOURCE/_GNU_SOURCE/_BSD_SOURCE. > > > > Я все-таки надеюсь, что strlcat и strlcpy раньше или позже будут в glibc: > > https://sourceware.org/ml/libc-alpha/2016-01/msg00205.html > > > > Там оно тоже под __USE_MISC. > > > > Так что мне кажется, что правильнее всего было бы исправить > > tools/include/linux/string.h > > А как мы можем исправить tools/include/linux/string.h, если, например в Fedora > нет этой функции в принципе? Я думаю, что появление этих прототипов в Федоре - вопрос времени, может быть, уже в следующей версии glibc (2.24). Вот буквально сеегодня Флориан отправил 10-ю итерацию: https://sourceware.org/ml/libc-alpha/2016-05/msg00369.html > Т.е. апстрим в лице kernel.org это вряд ли примет, > пока эта функция не появится там официально. Или речь идет о локальной правке? Честно говоря, я не вижу никаких механизмов в tools, которые бы позволили красиво пропатчить tools/include/linux/string.h таким образом, чтобы он работал у всех. Можно написать авторам, что назревает проблема, может быть, они какой-нибудь механизм придумают.
Создал https://bugzilla.kernel.org/show_bug.cgi?id=118481
(In reply to comment #4) > Создал https://bugzilla.kernel.org/show_bug.cgi?id=118481 Спасибо.
(In reply to Dmitry V. Levin from comment #5) > (In reply to comment #4) > > Создал https://bugzilla.kernel.org/show_bug.cgi?id=118481 > > Спасибо. Наверное, можно закрывать?
(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #6) > (In reply to Dmitry V. Levin from comment #5) > > (In reply to comment #4) > > > Создал https://bugzilla.kernel.org/show_bug.cgi?id=118481 > > > > Спасибо. > > Наверное, можно закрывать? Ту багу? Да, конечно.
(In reply to Dmitry V. Levin from comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > (In reply to comment #0) .... > Я думаю, что появление этих прототипов в Федоре - вопрос времени, может > быть, уже в следующей версии glibc (2.24). > Вот буквально сеегодня Флориан отправил 10-ю итерацию: > https://sourceware.org/ml/libc-alpha/2016-05/msg00369.html Есть ли новости из апстрима?
(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #8) > Есть ли новости из апстрима? https://git.kernel.org/torvalds/c/6c4798d3f08b81c2c52936b10e0fa872590c96ae
- Закрываю, т.к. в ядре приложен костыль.
