On Fri 2008-11-07 12:43, Hendrik Sattler wrote: > Jed Brown schrieb: > >>>> The FindPkgConfig.cmake module looks broken too, it assumes that > >>>> > >>>> -L/A -la -L/B -lb > >>>> > >>>> is equivalent to > >>>> > >>>> -L/A -L/B -la -lb > >>>> > >>> I don't see where the above would fail. > > > > This can also fail, but I should have written > > > > -L/B -L/A -la -lb > > > > since the existing modules are doing two things wrong. When the > > compiler parses the link line, it builds a stack of libraries to search. > > This stack must be searched incrementally. > > I'd ask the author of B first, why the H*** he has to use the same > library name that is already used by A, especially since he uses A. > That is broken in itself because if you install A and B with the same > prefix, B is broken.
Everyone should namespace their shared libs, but that's not the issue I'm concerned with. Suppose I'm parsing the link line /opt/mpich2/bin/mpicc -L/usr/lib -lumfpack -L/opt/mpich2/lib -lhdf5 where /usr/lib/libhdf5.a exists, but is not built with the parallel interface or is built against the default (ABI-incompatible) MPI implementation which resides at prefix=/usr. Umfpack is not a parallel library so I can't expect users to install a copy in /opt/mpich2 just so the third-party library whose link-line I'm parsing can be linked against the version sitting in /opt/mpich2/lib. However, it's essential that -lhdf5 resolve to /opt/mpich2/lib/hdf5.a otherwise everything will build successfully but my user will have a binary which seg-faults. > If you really need such specific linker behaviour (and who tells you > that all linkers behave like this?), you actually already messed up. The semantics are required for many linking cases such as variants on the example above. It's essential that they are resolved the way the linker will resolve them. Also remember that I'm parsing the link line from an interface library; I don't have control over what's there, but the interface library is asserting that if I link my library with precisely that link line, I will have a working binary. CMake requires every FindXXX.cmake module to resolve the link lines to absolute paths, not respecting linker semantics in such circumstances is a bug. Jed
pgpwjXD6JyFv5.pgp
Description: PGP signature
_______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
