>> 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. > 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. -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
