[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: library checks are driving me crazy!

From: aaragon
Subject: Re: library checks are driving me crazy!
Date: Sun, 23 Mar 2008 22:42:32 -0700 (PDT)

Hi, thanks for replying. I tried what you mentioned but that didn't solve the
problem either. I don't think the problem is a cyclic one. As I mentioned
before, there are two built blas libraries in my system. Is it possible that
the linker is looking for symbols at the wrong place? I want the library to
use the built one, not the one in the system, so when I hard-code the
location of the library in the file, it compiles fine (see
above). Is there a way to know the priority in which the libraries are
searched? If there is a priority list, I think that giving the flags should
put the path that I give prior to any system files.

Any other ideas??

Bob Proulx wrote:
> aaragon wrote:
>> Brian Dessent wrote:
>> > aaragon wrote:
>> >> ... LIBS="-lblas -lsuperlu_3.0 -lCGAL -lloki" ...
>> >> Those symbols belong to the blas library. So it turns out that superlu
>> >> depends on the blas library. I compiled superlu with its own blas
>> library
>> >> so
>> > 
>> > The order that you specify things to the linker matters.  If
>> > -lsuperlu_3.0 needs symbols from -lblas then it should come before it
>> in
>> > LIBS.
>> I actually tried both ways before posting and none work, I have the same
>> error.
> It may be that they have done the bad thing of creating a circular
> dependency.  In that case both must come before the other.  That's bad
> but unfortunately not fatal.  I say unfortunately because if it were
> fatal then people would be stopped from doing it.
> In the case of circular dependencies you may need to specify the
> libraries multiple times.  Perhaps something like this:
>   LIBS="-lblas -lsuperlu_3.0 -lblas -lCGAL -lloki"
> The linker scans across the line left to right and pulls in code to
> satisfy unresolved symbols that are unresolved at that point in the
> link.  As code is pulled in that creates more unresolved symbols from
> a previous library it may be necessary to list previously scanned libs
> again.  And even again if needed.
>   LIBS="-lblas -lsuperlu_3.0 -lblas -lCGAL -lloki -lsuperlu_3.0 -lblas"
> I showed an extreme example above and I hope it doesn't come to that
> but sometimes in the face of bad project design these types of things
> are needed to work around the problems.
> By the way...  If this is the problem then this is just a problem of
> misdesign in this project and doesn't really have anything to do with
> autoconf.  The same would be true if they were not using autoconf.
> When I am debugging these types of issues I will cut and paste just
> the link line from the build to be able to reproduce the link on the
> command line without using 'make' or other tools.  Then debug down to
> root cause from there.  After determining what the flags need to be
> then I can reconfigure using those flags.  This avoids the configure
> and full project make overhead which I fear you may be looping
> through and reduces the problem to just the link phase of the build.
> Bob
> _______________________________________________
> Autoconf mailing list
> address@hidden

View this message in context:
Sent from the Gnu - Autoconf - General mailing list archive at

reply via email to

[Prev in Thread] Current Thread [Next in Thread]