blob: 28fff6a82538063c622c0e77c697fa8fbe29a6d6 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
* If NIX_DEBUG is turned on (set to "1"), autoconf configure scripts
may fail to find the correct preprocessor:
checking how to run the C preprocessor... /lib/cpp
* When building gcc using a Nix gcc, generated libraries link against
the libraries of the latter:
$ ldd /nix/store/3b1d3995c4edbf026be5c73f66f69245-gcc-3.3.3/lib/libstdc++.so
...
libgcc_s.so.1 => /nix/store/1f19e61d1b7051f1131f78b41b2a0e7e-gcc-3.3.2/lib/libgcc_s.so.1 (0x400de000)
(wrong! should be .../3b1d.../lib/libgcc_s...)
...
* In libXt:
/bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -DXTHREADS -DXUSE_MTSAFE_API -I/nix/store/aadf0bd4a908da11d14f6538503b8408-libX11-6.2.1/include -I/nix/store/ba366e3b944ead64ec9b0490bb615874-xproto-6.6.1/include -I./include/X11 -g -O2 -c -o ActionHook.lo `test -f 'ActionHook.c' || echo './'`ActionHook.c
mkdir .libs
gcc -DHAVE_CONFIG_H -I. -I. -I. -DXTHREADS -DXUSE_MTSAFE_API -I/nix/store/aadf0bd4a908da11d14f6538503b8408-libX11-6.2.1/include -I/nix/store/ba366e3b944ead64ec9b0490bb615874-xproto-6.6.1/include -I./include/X11 -g -O2 -c ActionHook.c -fPIC -DPIC -o .libs/ActionHook.o
In file included from IntrinsicI.h:55,
from ActionHook.c:69:
include/X11/IntrinsicP.h:54:27: X11/Intrinsic.h: No such file or directory
* Then:
gcc -DHAVE_CONFIG_H -I. -I. -I. -DXTHREADS -DXUSE_MTSAFE_API -I/nix/store/aadf0bd4a908da11d14f6538503b8408-libX11-6.2.1/include -I/nix/store/ba366e3b944ead64ec9b0490bb615874-xproto-6.6.1/include -I./include -I./include/X11 -g -O2 -c ActionHook.c -fPIC -DPIC -o .libs/ActionHook.o
In file included from IntrinsicI.h:55,
from ActionHook.c:69:
include/X11/IntrinsicP.h:202:25: X11/ObjectP.h: No such file or directory
(moved to include/X11; should edit include/Makefile.am)
* `ld' on Mac OS X barfs if the timestamp on static libraries has
changed (which happens if they are installed through a substitute).
Typical error:
/usr/bin/ld: table of contents for archive: libATerm.a is out of
date; rerun ranlib(1) (can't load from it)
Solution: patch ld.
Non-solution: extend NAR file format to include timestamps. We
don't want that because they introduce a source of non-determinism.
To catch problems like this one determistically, we should change
the timestamp on store objects to 0.
* In gtksourceview-sharp: does the prefix patch cause problems (e.g.,
makefile.am says "mimeinfodir should be the same as the gnome
prefix")?
* fgrep/egrep: these fail if grep is not in the $PATH.
* teTeX: some programs (such as epstopdf) depend on /usr/bin/env, and
expect perl to be in the environment.
|