32108 2016-05-17 16:46:16 +0300 Q: why our glibc-devel provides strlcpy? 2021-06-15 10:34:18 +0300 1 1 4 Development Sisyphus glibc-devel unstable all Linux CLOSED FIXED http://marc.info/?i=1421156604-30603-3-git-send-email-vgupta%40synopsys.com relnote P3 normal --- 1 lakostis glebfm evg glebfm lav ldv qa-sisyphus oldest_to_newest 156841 0 lakostis 2016-05-17 16:46:16 +0300 Почему-то только мы и 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 156842 1 ldv 2016-05-17 17:27:52 +0300 (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 156850 2 lakostis 2016-05-18 01:09:38 +0300 (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 это вряд ли примет, пока эта функция не появится там официально. Или речь идет о локальной правке? 156855 3 ldv 2016-05-18 16:42:34 +0300 (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 таким образом, чтобы он работал у всех. Можно написать авторам, что назревает проблема, может быть, они какой-нибудь механизм придумают. 156860 4 lakostis 2016-05-19 12:11:08 +0300 Создал https://bugzilla.kernel.org/show_bug.cgi?id=118481 156866 5 ldv 2016-05-19 17:30:49 +0300 (In reply to comment #4) > Создал https://bugzilla.kernel.org/show_bug.cgi?id=118481 Спасибо. 188776 6 lakostis 2020-03-25 00:21:47 +0300 (In reply to Dmitry V. Levin from comment #5) > (In reply to comment #4) > > Создал https://bugzilla.kernel.org/show_bug.cgi?id=118481 > > Спасибо. Наверное, можно закрывать? 188780 7 ldv 2020-03-25 00:32:47 +0300 (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 > > > > Спасибо. > > Наверное, можно закрывать? Ту багу? Да, конечно. 196192 8 lakostis 2021-02-11 22:50:52 +0300 (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 Есть ли новости из апстрима? 196203 9 ldv 2021-02-12 00:13:11 +0300 (In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #8) > Есть ли новости из апстрима? https://git.kernel.org/torvalds/c/6c4798d3f08b81c2c52936b10e0fa872590c96ae 199189 10 lakostis 2021-06-15 10:34:18 +0300 - Закрываю, т.к. в ядре приложен костыль.