nixpkgs/maintainers/docs/bugs.txt

* 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")?