Re: library checks are driving me crazy!

[aaragon]

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 Makefile.am 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
> http://lists.gnu.org/mailman/listinfo/autoconf
> 
> 

-- 
View this message in context: 
http://www.nabble.com/library-checks-are-driving-me-crazy%21-tp16245235p16245823.html
Sent from the Gnu - Autoconf - General mailing list archive at Nabble.com.