[Nix-dev] yate

[Lluís Batlle]

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 <marco-oweber at gmx.de>:
> 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
> nix-dev at cs.uu.nl
> https://mail.cs.uu.nl/mailman/listinfo/nix-dev
>