qmake configured correctly for multiarch library directories?

[Josh Stratton]

>> 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.