b****y
发帖数: 169 | 1 我的glibc2.5是在2.6.11下编译的。
如果我升级到2.6.30需要重新编译glibc吗？
谢谢！ |
s****n
发帖数: 786 | 2 如果你编译的时候kernel-headers也是2.6.11，你还是需要重新编译glibc
否则glibc在新kernel下可能不工作，如果你用了更新的头文件，可能可以工作。
2.6.12以后变化很大
【在 b****y 的大作中提到】
: 我的glibc2.5是在2.6.11下编译的。
: 如果我升级到2.6.30需要重新编译glibc吗？
: 谢谢！
|
b****y
发帖数: 169 | 3 如果我冒死编译，安装2.6.30，之后能启动吗？
我这是一个embeded system。会不会dropbear都不工作了？
我是否还有机会通过串口登陆，编译，安装glibc?
还是说我一趟把kernel, glibc都编译安装好了再重启？然后祈祷...
多谢！ |
S*A
发帖数: 7142 | 4 应该问题不大。kernel 虽然更新很快，但是 kernel / user space
的 API 更新不是那么快，很多东西是加新的 feature, 向下兼容的。
夸张点你拿 uclinux 那些超级老的 libc 在新的 kernel 也能跑起来
呢。很多 embed linux 都是这么干的。所以我觉得问题不大。
【在 b****y 的大作中提到】
: 我的glibc2.5是在2.6.11下编译的。
: 如果我升级到2.6.30需要重新编译glibc吗？
: 谢谢！
|
S*A
发帖数: 7142 | 5 应该没有问题的。glibc 几乎是一直向下兼容的。我还没有听说这个
interface 会让旧的 glibc 不能跑的变化。这就是 kernel 重来不
改变 system call API 的原因。例如新的 mmap 是加一个 mmap2 的
system call. 然后内部把旧的 mmap system call 翻译到等价的 mmap2
上面去。不会直接换 mmap system call 的。
kernel developer 非常注意不干这种 break glibc 向下兼容的事情的。
因为就 kernel developer 自己就很不方便，你要 bisect 一个 kernel
regression 还要换 glibc？ Linus 那关肯定就过不了。
有其他的东西可能会导致换新 kernel 跑不起来，例如 udev, modprobe
这些东西。但是你什么时候注意到新 kernel 让旧的 libc 跑不起来的？
我是没有见过。
【在 s****n 的大作中提到】
: 如果你编译的时候kernel-headers也是2.6.11，你还是需要重新编译glibc
: 否则glibc在新kernel下可能不工作，如果你用了更新的头文件，可能可以工作。
: 2.6.12以后变化很大
|
S*A
发帖数: 7142 | 6 如果有这么一个改动让旧的 glibc 不能用的话，
这就意味着你做 "git pull" 然后编译新的 kernel 之后
你的系统就起不来了。这个改动强制大家升级 glibc 会挨很多砖头的。 |
s****n
发帖数: 786 | 7 glibc要是有问题根本启动不了，dropbear就别想了，不过你既然有串口，又是
embedded, 随时用bootloader重新烧不行吗？
不知道你是什么系统，最好交叉编译，直接在目标系统编译简直开玩笑。
【在 b****y 的大作中提到】
: 如果我冒死编译，安装2.6.30，之后能启动吗？
: 我这是一个embeded system。会不会dropbear都不工作了？
: 我是否还有机会通过串口登陆，编译，安装glibc?
: 还是说我一趟把kernel, glibc都编译安装好了再重启？然后祈祷...
: 多谢！
|
s****n
发帖数: 786 | 8 kernel developer自己就和glibc developer打过架，这都很有名的公案。。。
lz用的是2.6.11，这个版本刚好有点尴尬。
【在 S*A 的大作中提到】
: 应该没有问题的。glibc 几乎是一直向下兼容的。我还没有听说这个
: interface 会让旧的 glibc 不能跑的变化。这就是 kernel 重来不
: 改变 system call API 的原因。例如新的 mmap 是加一个 mmap2 的
: system call. 然后内部把旧的 mmap system call 翻译到等价的 mmap2
: 上面去。不会直接换 mmap system call 的。
: kernel developer 非常注意不干这种 break glibc 向下兼容的事情的。
: 因为就 kernel developer 自己就很不方便，你要 bisect 一个 kernel
: regression 还要换 glibc？ Linus 那关肯定就过不了。
: 有其他的东西可能会导致换新 kernel 跑不起来，例如 udev, modprobe
: 这些东西。但是你什么时候注意到新 kernel 让旧的 libc 跑不起来的？
|
S*A
发帖数: 7142 | 9 faint. 你是说 drepper 么，这家伙和谁不打架来着？我都
没法知道你想引用的是哪一个 case 了。再说了， kernel
developer 自己在 lkml 上面掐架很正常啊，哪个大点的改动
是没有掐过的，就是正常的开发模式的一部分。林子大了，
众口难调，讨论一下是正常的。
你是知道什么 kernel 2.6.11 以后不向下兼容 glibc 的例子么？
具体说说？
【在 s****n 的大作中提到】
: kernel developer自己就和glibc developer打过架，这都很有名的公案。。。
: lz用的是2.6.11，这个版本刚好有点尴尬。
|
r*****z
发帖数: 906 | 10 插一句：最最近的memcpy问题，应该也算是kernel和glibc开发者闹别扭的事情
【在 S*A 的大作中提到】
: faint. 你是说 drepper 么，这家伙和谁不打架来着？我都
: 没法知道你想引用的是哪一个 case 了。再说了， kernel
: developer 自己在 lkml 上面掐架很正常啊，哪个大点的改动
: 是没有掐过的，就是正常的开发模式的一部分。林子大了，
: 众口难调，讨论一下是正常的。
: 你是知道什么 kernel 2.6.11 以后不向下兼容 glibc 的例子么？
: 具体说说？
|
|
|
S*A
发帖数: 7142 | 11 比较孤陋寡闻，你说的是那个事情？
听上去很不解啊， 很难想象 kernel break glibc 的 memcpy.
glibc 的 memcpy 关 kernel 什么事呢？
如果说是在 kernel 引用 glibc 的 memcpy， 那完全是 kernel
内部的问题，和 LZ 关心的 kernel & glibc 兼容性是两回事。
【在 r*****z 的大作中提到】
: 插一句：最最近的memcpy问题，应该也算是kernel和glibc开发者闹别扭的事情
|
S*A
发帖数: 7142 | 12 google 了一下 memcpy, kernel, lkml.
没有找到什么有用的。 唯一一个接近的是 memcpy 和 memmove
要区分开。但是这个 memcpy 完全是 user space 自己的事情啊。
跟 kernel 没有什么关系啊，还是非常不解。 |
b****y
发帖数: 169 | 13 两位大牛的讨论让我受益匪浅。
没错，我是可以通过串口重烧kernel image
不过升级kernel除了改image, 是否还要更新文件系统里的其他部分？
kernel module应该是一个，不过是按kernel版本存放的。
还有其他的么？
SSA提到的udev可能会是一个问题。我现在是devfs, 新的kernel里还有吧？还是必须升
级到udev?
mod_probe 是个什么问题？
我的系统是PowerPC 603e。我以前也交叉编译，但总有一些小问题。现在目标上编译虽
然慢一些，但是省心多了。大不了编译个3天，只要别出错。 |
S*A
发帖数: 7142 | 14
要。
modutils. 这个新版的 kernel modutils 完全变了。什么时候
变的我已经不记得了。
devfs 好像已经死翘翘了。udev 一统天下了。不知道有没有兼容模式，我已经
很久没有碰 devfs 了。
modutils. 装 module 的方式， module deps 这些都彻底变了。
三天？ 一个小时应该就可以了吧？
【在 b****y 的大作中提到】
: 两位大牛的讨论让我受益匪浅。
: 没错，我是可以通过串口重烧kernel image
: 不过升级kernel除了改image, 是否还要更新文件系统里的其他部分？
: kernel module应该是一个，不过是按kernel版本存放的。
: 还有其他的么？
: SSA提到的udev可能会是一个问题。我现在是devfs, 新的kernel里还有吧？还是必须升
: 级到udev?
: mod_probe 是个什么问题？
: 我的系统是PowerPC 603e。我以前也交叉编译，但总有一些小问题。现在目标上编译虽
: 然慢一些，但是省心多了。大不了编译个3天，只要别出错。
|
s*******n
发帖数: 2828 | 15 成天升级内核，表示无压力，从来没特意编译glibc过
【在 s****n 的大作中提到】
: 如果你编译的时候kernel-headers也是2.6.11，你还是需要重新编译glibc
: 否则glibc在新kernel下可能不工作，如果你用了更新的头文件，可能可以工作。
: 2.6.12以后变化很大
|
s*******n
发帖数: 2828 | 16 我中了这个，巨雷人，症状居然表现在flash播放的声音上
redhat上有大量嘴仗，linus也参加进来了
【在 S*A 的大作中提到】
: 比较孤陋寡闻，你说的是那个事情？
: 听上去很不解啊， 很难想象 kernel break glibc 的 memcpy.
: glibc 的 memcpy 关 kernel 什么事呢？
: 如果说是在 kernel 引用 glibc 的 memcpy， 那完全是 kernel
: 内部的问题，和 LZ 关心的 kernel & glibc 兼容性是两回事。
|
s*******n
发帖数: 2828 | 17 https://bugzilla.redhat.com/show_bug.cgi?id=638477
在这里
【在 S*A 的大作中提到】
: google 了一下 memcpy, kernel, lkml.
: 没有找到什么有用的。 唯一一个接近的是 memcpy 和 memmove
: 要区分开。但是这个 memcpy 完全是 user space 自己的事情啊。
: 跟 kernel 没有什么关系啊，还是非常不解。
|
S*A
发帖数: 7142 | 18 啊多谢 Link。这个就是我说的 memcpy vs memmove 的东西。
这个跟 kernel 完全没有关系，就是 glibc 和 flash 之间的
问题。完全是 user space, 不能因为 Linus 跳进来讨论就自
动变成 kernel 问题了。
而且 Linus 一再强调尽量保持 binary interface 的重要性。
这个和 kernel 不应该 break glibc 里讨论的原因是完全
一致的。非常典型的 Linus 的一贯立场啊。所以我相信破坏
glibc 兼容性的改动过不了 Linus 那一关的。
https://bugzilla.redhat.com/show_bug.cgi?id=638477#c222
什么时候变成 kernel vs glibc 的兼容性问题了？
【在 s*******n 的大作中提到】
: https://bugzilla.redhat.com/show_bug.cgi?id=638477
: 在这里
|
S*A
发帖数: 7142 | 19 这个就对了。
【在 s*******n 的大作中提到】
: 成天升级内核，表示无压力，从来没特意编译glibc过
|
S*A
发帖数: 7142 | 20 再看看这个 bug, 严重同意 Linus 的观点。
这就是为什么大家很信任 Linus 的原因，因为他比较敏锐指出
问题的实质，提出比较实际的解决方案，不同于传统的习惯思维。
一般人骂骂 flash 就完了。Linus 要求 glibc 吧 memcpy
实现成 memmove 的确是更加完美的方案。
Linus is always right. 又一次成功的体现。 |
|
|
s*******n
发帖数: 2828 | 21 教主千秋万载，一统江湖
【在 S*A 的大作中提到】
: 再看看这个 bug, 严重同意 Linus 的观点。
: 这就是为什么大家很信任 Linus 的原因，因为他比较敏锐指出
: 问题的实质，提出比较实际的解决方案，不同于传统的习惯思维。
: 一般人骂骂 flash 就完了。Linus 要求 glibc 吧 memcpy
: 实现成 memmove 的确是更加完美的方案。
: Linus is always right. 又一次成功的体现。
|
r*****z
发帖数: 906 | 22 不是兼容性问题，而是理念差异
glibc的开发人员希望逐渐向标准靠拢，修改不符合标准的行为，无论有多少代价
【在 S*A 的大作中提到】
: google 了一下 memcpy, kernel, lkml.
: 没有找到什么有用的。 唯一一个接近的是 memcpy 和 memmove
: 要区分开。但是这个 memcpy 完全是 user space 自己的事情啊。
: 跟 kernel 没有什么关系啊，还是非常不解。
|
S*A
发帖数: 7142 | 23 这个我还是完全同意 Linus 教主。
标准是人订的，最终是为人服务的。
memcpy 用 memmove 实现完全没有违反任何标准。
用损害用户使用来片面刻板强制标准是不可取的。
大不了给个 debug mode Warning 那些不标准行为。
直接 corrupt 是完全不必要的。
【在 r*****z 的大作中提到】
: 不是兼容性问题，而是理念差异
: glibc的开发人员希望逐渐向标准靠拢，修改不符合标准的行为，无论有多少代价
|
