| View previous topic :: View next topic |
| Author |
Message |
yemu
Guru
Joined: 05 Jun 2003
Posts: 342
Location: /poland/warsaw
|
 Posted: Wed May 26, 2004 10:01 am Post subject: problem with /lib/cpp when compiling |
 |
|
hi!
i can't emerge or compile manually any package. the error is at "configure" phase. it says something about a problem with /lib/cpp
| Code: |
checking how to run the C preprocessor... /lib/cpp
configure: error: C preprocessor "/lib/cpp" fails sanity check
|
also portage doesn't emerge, but with some different error
| Code: |
bash-2.05b# emerge portage
Calculating dependencies ...done!
>>> emerge (1 of 1) sys-apps/portage-2.0.50-r6 to /
>>> md5 src_uri ;-) portage-2.0.50-r6.tar.bz2
>>> Unpacking source...
>>> Unpacking portage-2.0.50-r6.tar.bz2 to /var/tmp/portage/portage-2.0.50-r6/work
>>> Source unpacked.
In file included from /usr/include/errno.h:36,
from tbz2tool.c:7:
/usr/include/bits/errno.h:25:26: linux/errno.h: No such file or directory
./create-localdecls
Checking truncate argument type... off_t
Checking libc version... libc.so.6
Checking glibc subversion... 2.3
gcc -march=i386 -O1 -pipe -D_GNU_SOURCE -DPIC -fPIC -D_REENTRANT -Wall -c libsandbox.c
In file included from /usr/include/bits/posix1_lim.h:130,
from /usr/include/dirent.h:221,
from libsandbox.c:52:
/usr/include/bits/local_lim.h:36:26: linux/limits.h: No such file or directory
In file included from /usr/include/errno.h:36,
from libsandbox.c:54:
/usr/include/bits/errno.h:25:26: linux/errno.h: No such file or directory
In file included from libsandbox.c:63:
/usr/include/sys/param.h:23:26: linux/limits.h: No such file or directory
/usr/include/sys/param.h:24:25: linux/param.h: No such file or directory
In file included from libsandbox.c:78:
localdecls.h:21:3: #error PATH_MAX not defined!
libsandbox.c: In function `canonicalize':
libsandbox.c:288: error: `EINVAL' undeclared (first use in this function)
libsandbox.c:288: error: (Each undeclared identifier is reported only once
libsandbox.c:288: error: for each function it appears in.)
libsandbox.c:305: error: `ENAMETOOLONG' undeclared (first use in this function)
libsandbox.c:308: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:318: error: `ENOENT' undeclared (first use in this function)
libsandbox.c: In function `chmod':
libsandbox.c:366: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:366: warning: unused variable `canonic'
libsandbox.c: In function `chown':
libsandbox.c:383: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:383: warning: unused variable `canonic'
libsandbox.c: In function `creat':
libsandbox.c:401: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:401: warning: unused variable `canonic'
libsandbox.c: In function `fopen':
libsandbox.c:418: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:418: warning: unused variable `canonic'
libsandbox.c: In function `lchown':
libsandbox.c:436: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:436: warning: unused variable `canonic'
libsandbox.c: In function `link':
libsandbox.c:453: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:453: warning: unused variable `old_canonic'
libsandbox.c:453: warning: unused variable `new_canonic'
libsandbox.c: In function `mkdir':
libsandbox.c:472: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:479: error: `EEXIST' undeclared (first use in this function)
libsandbox.c:472: warning: unused variable `canonic'
libsandbox.c: In function `opendir':
libsandbox.c:497: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:497: warning: unused variable `canonic'
libsandbox.c: In function `open':
libsandbox.c:538: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:538: warning: unused variable `canonic'
libsandbox.c: In function `rename':
libsandbox.c:564: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:564: warning: unused variable `old_canonic'
libsandbox.c:564: warning: unused variable `new_canonic'
libsandbox.c: In function `rmdir':
libsandbox.c:582: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:582: warning: unused variable `canonic'
libsandbox.c: In function `symlink':
libsandbox.c:599: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:599: warning: unused variable `old_canonic'
libsandbox.c:599: warning: unused variable `new_canonic'
libsandbox.c: In function `truncate':
libsandbox.c:617: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:617: warning: unused variable `canonic'
libsandbox.c: In function `unlink':
libsandbox.c:634: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:634: warning: unused variable `canonic'
libsandbox.c: In function `creat64':
libsandbox.c:654: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:654: warning: unused variable `canonic'
libsandbox.c: In function `fopen64':
libsandbox.c:671: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:671: warning: unused variable `canonic'
libsandbox.c: In function `open64':
libsandbox.c:691: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:691: warning: unused variable `canonic'
libsandbox.c: In function `truncate64':
libsandbox.c:714: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:714: warning: unused variable `canonic'
libsandbox.c: In function `execve':
libsandbox.c:740: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c:764: error: `ENOMEM' undeclared (first use in this function)
libsandbox.c:740: warning: unused variable `canonic'
libsandbox.c: In function `filter_path':
libsandbox.c:992: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c: In function `check_syscall':
libsandbox.c:1182: error: `SB_PATH_MAX' undeclared (first use in this function)
libsandbox.c: In function `before_syscall':
libsandbox.c:1309: error: `ENOENT' undeclared (first use in this function)
libsandbox.c:1336: error: `EACCES' undeclared (first use in this function)
In file included from libsandbox.c:1363:
getcwd.c: In function `__egetcwd':
getcwd.c:296: error: `EINVAL' undeclared (first use in this function)
getcwd.c:300: error: `SB_PATH_MAX' undeclared (first use in this function)
getcwd.c:415: error: `ENOENT' undeclared (first use in this function)
getcwd.c:424: error: `ERANGE' undeclared (first use in this function)
getcwd.c:434: error: `ENOMEM' undeclared (first use in this function)
In file included from libsandbox.c:1363:
getcwd.c: In function `egetcwd':
getcwd.c:501: error: `ENOENT' undeclared (first use in this function)
In file included from libsandbox.c:1364:
canonicalize.c: In function `erealpath':
canonicalize.c:68: error: `EINVAL' undeclared (first use in this function)
canonicalize.c:75: error: `ENOENT' undeclared (first use in this function)
canonicalize.c:133: error: `ENAMETOOLONG' undeclared (first use in this function)
make: *** [libsandbox.o] Error 1
!!! ERROR: sys-apps/portage-2.0.50-r6 failed.
!!! Function src_compile, Line 44, Exitcode 2
!!! (no error message) |
thanks for any suggestions
best regards
y
_________________
Centrum Jêzyka Francuskiego VOILA - http://www.voila.edu.pl |
|
| Back to top |
|
 |
moocha
Watchman
Joined: 21 Oct 2003
Posts: 5722
|
| Posted: Wed May 26, 2004 10:43 am Post subject: |
|
|
I think the two problems have the same cause.
Let me guess - /usr/include/linux is a symlink to /usr/src/linux-whatever-version/include/linux, and you've unmerged that specific kernel source package. One should never ever symlink /usr/src/linux into the kernel source tree. Ever.
Run | Code: | | file /usr/include/linux |
to confirm - it'll report a symlink if that was done.
Re-emerge sys-kernel/linux-headers.
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
| Back to top |
|
|
yemu
Guru
Joined: 05 Jun 2003
Posts: 342
Location: /poland/warsaw
|
| Posted: Wed May 26, 2004 11:33 pm Post subject: |
|
|
thanks! i actually managed to solve the problem myself, but the reasen you've mentioned was almost true. actually i've done something more stupid than symlinking kernel-sources from /usr/src - i unmerged kernel-headers package...i merged it and everything's fine again.
BTW, could you tell me why shouldn't i link /usr/include/linux to /usr/src/........ ? linux header package is older (2.4.22) than kernel i use (2.4.26_pre6), is it normal?
thanks again
cheers
y
_________________
Centrum Jêzyka Francuskiego VOILA - http://www.voila.edu.pl |
|
| Back to top |
|
|
moocha
Watchman
Joined: 21 Oct 2003
Posts: 5722
|
| Posted: Wed May 26, 2004 11:43 pm Post subject: |
|
|
Glad to hear it's solved 
Well, the first and obvious reason is that if you remove the kernel sources you can't compile anything  .
The second (and actually the most important) reason is glibc. Whenever you upgrade the kernel headers you should also upgrade / recompile glibc. You might get away with not recompiling that big package if you move from, say, headers 2.4.18 to headers 2.4.19, or from 2.6.1 to 2.6.2. Maybe. But a bigger jump should always be followed by a recompile of glibc.
Why? Oversimplified: The headers describe the layout of certain data structures. Programs use these headers, get compiled, and link against glibc. They pass to and from glibc data structures with the layout they know (which was defined by the headers they were compiled with). But if glibc was compiled against a different set of headers then trouble might arise - some data structure or the other may have changed its internal layout, and you can imagine the consequences. Causes some pretty hard to track down bugs.
The point is that the kernel header version and glibc should be kept in sync - and if someone links from /usr/include/linux into the kernel source tree the current headers get out of sync with every new kernel source. That's pretty much asking for trouble to come and bite you in the ass when you least expect it
Edit: Forgot to add: There's nothing to worry about if your headers are from the 2.4 series and your kernel from the 2.6 series. Really. Just as long glibc and the headers get along fine
You can of course upgrade to the 2.6 headers if you want, but they're still -*-masked for some reason (probably the usual one - their impact hasn't been studied enough yet to cause them to go mainstream).
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Duplicate Threads
