octave-maintainers
[Top][All Lists]
Advanced

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

Re: eigs and ARPACK


From: Thomas Treichl
Subject: Re: eigs and ARPACK
Date: Sat, 03 Jan 2009 20:39:54 +0100
User-agent: Thunderbird 2.0.0.19 (Macintosh/20081209)

David Bateman schrieb:
Thomas Treichl wrote:

That's it right now, I hope I could give some feedback...

Best regards,

  Thomas

Thomas thanks for the report, yes it did help even if I'm late in replying. I hope to have a patch soon, if I can figure out my linking issue.

Well, I'm even more slow ;) The ARPACK beast made some problems on my Mac but finally I found out that all the problems disappear if I just use g95 to create libarpack.dylib (instead of f2c). The usage of g95 for libarpack.dylib now makes me thinking about some more other things...

At the moment I still have the problem that linking of liboctave.dylib fails because of undefined symbols:

  ld: Undefined symbols:
  _dnaupd_
  _dneupd_
  _dsaupd_
  _dseupd_
  _znaupd_
  _zneupd_
  /usr/libexec/gcc/i686-apple-darwin8/4.0.1/libtool:
    internal link edit command failed

that's why I added "$(ARPACK_LIBS)" to "LINK_DEPS" of "Makefile.in" in the directory of liboctave. I cheated, and also compiled the latest Octave sources on my virtual Debian GNU/Linux box. That system doesn't need to know anything about $(ARPACK_LIBS) for liboctave.so but just compiles fine without that information - can you help me to understand where GNU/Linux gets it's information about these functions from? Is my hack the right thing that should be done or am I missing something?

Best regards,

  Thomas


reply via email to

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