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 > Autoconf@xxxxxxx > 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. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
