Try to build with the env NIX_DEBUG=1, and see what is finally passed to the real gcc.
I think the gcc wrappers take out -L paths if the path is not considered in the store, and the algorithm may fail on -L.. Using "-v" with gcc will also tell you the exact parameters 'ld' is called with. 2009/10/3 Marc Weber <[email protected]>: > I'm interested in yate. > > However the build fails this way: > > g++ -Wall -I.. -I.. -O2 -fno-check-new -fno-exceptions -fPIC > -DHAVE_GCC_FORMAT_CHECK -export-dynamic -shared > -Wl,--unresolved-symbols=ignore-in-shared-libs -Wl,--retain-symbols-file -L.. > -lyate -o cdrbuild.yate cdrbuild.cpp [b > /nix/store/1yv8i1m76cvwk5w5i5wrk4gj5zyfj6vh-binutils-2.19.1/bin/ld: > --library=yate: No such file or directory > > This command is run from $TMP/yate/modules > So the -L.. option is correct > > This proofs that the file is there: > > ls -l libyate.so > lrwxrwxrwx 1 marc nixbld 16 2009-10-02 23:37 libyate.so -> libyate.so.2.0.0 > > 73z9yyb-yate2.drv-0/yate ]$ file libyate.so.2.0.0 > libyate.so.2.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), > dynamically linked, not stripped > > Any idea why ld called by g++ can't find it? Whatelse might be wrong? > > Marc Weber > _______________________________________________ > nix-dev mailing list > [email protected] > https://mail.cs.uu.nl/mailman/listinfo/nix-dev > _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
