1 |
2016-06-07 8:19 GMT+08:00 Lei Zhang <zhanglei.april@×××××.com>: |
2 |
> 2016-06-07 6:04 GMT+08:00 Felix Janda <felix.janda@××××××.de>: |
3 |
>> Lei Zhang wrote: |
4 |
>>> Hi, |
5 |
>>> |
6 |
>>> I was trying to run clang (built specifically for musl) on a chroot |
7 |
>>> musl system, and met some strange issue. After some investigation, it |
8 |
>>> turns out the function realpath() is giving me wrong results. |
9 |
>>> |
10 |
>>> I can reproduce the error with the following code snippet: |
11 |
>>> |
12 |
>>> #include <stdio.h> |
13 |
>>> #include <stdlib.h> |
14 |
>>> #include <limits.h> |
15 |
>>> |
16 |
>>> int main(int argc, char** argv) { |
17 |
>>> const char* path = "/usr/bin/clang"; // suppose this is a valid path |
18 |
>>> char resolved[PATH_MAX]; |
19 |
>>> char* ret = realpath(path, resolved); |
20 |
>>> |
21 |
>>> if (ret) |
22 |
>>> printf("%s\n", ret); |
23 |
>>> } |
24 |
>>> |
25 |
>>> If I build it against musl, it gives correct result on my host, but |
26 |
>>> wrong result on chroot; If I build it against glibc (statically, since |
27 |
>>> there's no glibc on chroot), it gives correct results on both |
28 |
>>> environments. So it looks like musl is to blame on the chroot |
29 |
>>> environment. I haven't yet confirmed if it's a bug. |
30 |
>>> |
31 |
>>> Any thoughts? |
32 |
>> |
33 |
>> With musl, realpath() (and some other things) depend on having a |
34 |
>> mounted /proc. |
35 |
> |
36 |
> You're right! |
37 |
> |
38 |
> After mounting /proc on the chroot system, the issue is resolved. At |
39 |
> this point I'm really not sure if this is musl's bug. Is it legit to |
40 |
> unconditionally depends on the presence of a mounted /proc? |
41 |
|
42 |
Answer from musl's mailing list: www.openwall.com/lists/musl/2016/06/07/2 |
43 |
|
44 |
|
45 |
Lei |