Bug 32108 - Q: why our glibc-devel provides strlcpy?
Summary: Q: why our glibc-devel provides strlcpy?
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: glibc-devel (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: placeholder@altlinux.org
QA Contact: qa-sisyphus
URL: http://marc.info/?i=1421156604-30603-...
Keywords: relnote
Depends on:
Blocks:
 
Reported: 2016-05-17 16:46 MSK by Konstantin A Lepikhov (L.A. Kostis)
Modified: 2021-06-15 10:34 MSK (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin A Lepikhov (L.A. Kostis) 2016-05-17 16:46:16 MSK
Почему-то только мы и 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
Comment 1 Dmitry V. Levin 2016-05-17 17:27:52 MSK
(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
Comment 2 Konstantin A Lepikhov (L.A. Kostis) 2016-05-18 01:09:38 MSK
(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 это вряд ли примет, пока эта функция не появится там официально. Или речь идет о локальной правке?
Comment 3 Dmitry V. Levin 2016-05-18 16:42:34 MSK
(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 таким образом, чтобы он работал у всех.  Можно написать авторам, что назревает проблема, может быть, они какой-нибудь механизм придумают.
Comment 4 Konstantin A Lepikhov (L.A. Kostis) 2016-05-19 12:11:08 MSK
Создал https://bugzilla.kernel.org/show_bug.cgi?id=118481
Comment 5 Dmitry V. Levin 2016-05-19 17:30:49 MSK
(In reply to comment #4)
> Создал https://bugzilla.kernel.org/show_bug.cgi?id=118481

Спасибо.
Comment 6 Konstantin A Lepikhov (L.A. Kostis) 2020-03-25 00:21:47 MSK
(In reply to Dmitry V. Levin from comment #5)
> (In reply to comment #4)
> > Создал https://bugzilla.kernel.org/show_bug.cgi?id=118481
> 
> Спасибо.

Наверное, можно закрывать?
Comment 7 Dmitry V. Levin 2020-03-25 00:32:47 MSK
(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
> > 
> > Спасибо.
> 
> Наверное, можно закрывать?

Ту багу?  Да, конечно.
Comment 8 Konstantin A Lepikhov (L.A. Kostis) 2021-02-11 22:50:52 MSK
(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


Есть ли новости из апстрима?
Comment 9 Dmitry V. Levin 2021-02-12 00:13:11 MSK
(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #8)
> Есть ли новости из апстрима?

https://git.kernel.org/torvalds/c/6c4798d3f08b81c2c52936b10e0fa872590c96ae
Comment 10 Konstantin A Lepikhov (L.A. Kostis) 2021-06-15 10:34:18 MSK
- Закрываю, т.к. в ядре приложен костыль.