-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/17/2012 04:09 PM, Josh Stratton wrote: >>> Like I said, the majority of my libraries are still in /usr/lib and now >>> qmake doesn't link against them by >>> default. Is this a bug? Is this just an accepted consequence of multiarch? >>> Or is there something I need to >>> configure that wasn't handled properly in my upgrade? >> >> Well, qmake only generates makefiles. GCC has /usr/lib hardcoded in its >> library resolver search path and is >> always used implicitly, so that should not be a problem. If qmake is not >> using its linker symbol ($(GXX) or >> $(LD)) to generate library search paths if it needs them explicitly, it is >> certainly a major bug in qmake and >> should have been noticed long ago. The multi-arch paths are in addition to >> the default paths, not instead of. > > I'm not very familiar with how that works. I know when I run cmake it will > add the -L/usr/lib and > -L/usr/lib/i386-linux-gnu to the makefiles, so is it just being redundant? > On another machine I tried a quick test > of adding a file to the LIBS path and it worked without -L/usr/lib being set > explicitly.
To see where GCC looks for libraries by default, run 'gcc -print-search-dirs | grep libraries'. In the absence of special options, using the -L switch will augment the library search path. Adding the standard paths to the command line is redundant. >> How do you know the /usr/lib libraries are not being linked against? What >> is the symptom, other than not >> appearing explicitly on the command line? > > The actual problem I experienced after upgrading was the missing library > assimp, which was still sitting in my > /usr/lib directory. Since the library file was still there and didn't see > /usr/lib explicitly included, I figured > that was the problem. I'm having similar issues with including aqsis, so it > seemed dubious that a handful of > packages were broken and more likely that it was some issue with qmake > specific to my machine. It's possible the library in /usr/lib is the wrong architecture, which would cause GCC to ignore it. You can use the 'file' utility to see whether a file in /usr/lib was built for i386 (ELF 32-bit LSB shared object, Intel 80386) or x86_64 (ELF 64-bit LSB shared object, x86-64). You can also force -L or -l flags explicitly when running 'make' after qmake by setting the LDFLAGS environment variable, if you want to experiment. - -- Stephen M. Webb <[email protected]> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+1p0AACgkQTLRKqWcl7vP5cQCfZziZvr35fM12zzNFBP3Gs7/0 HZsAn0rcc0cuxJv7SWZ2wxib0Jw0VLZP =40pI -----END PGP SIGNATURE----- -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
