[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ubuntu-devel
Subject:    qmake configured correctly for multiarch library directories?
From:       stephen () ubuntu ! com (Stephen M !  Webb)
Date:       2012-05-18 1:34:57
Message-ID: 4FB5A741.8050507 () ubuntu ! com
[Download RAW message or body]

-----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  <stephen at ubuntu.com>
-----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-----


[prev in list] [next in list] [prev in thread] [next in thread]