Reported by David Strubbe, Jun 7, 2013
ARPACK-NG 3.1.2 was building fine in MacPorts. I tried to udpate it to 3.1.3, but now I get the error: :info:build Making all in . :info:build make: Entering directory `/opt/local/var/macports/build/_Users_dstrubbe_Software_MacPorts_math _arpack/arpack/work/arpack-ng-3.1.3' :info:build /bin/sh ./libtool --tag=F77 --mode=link /opt/local/bin/gfortran-mp-4.6 -O2 -m64 -no-undefined -version-info 2:0 -L/opt/local/lib -o libarpack.la -rpath /opt/local/lib ./SRC/libarpacksrc.la ./UTIL/libarpackutil.la /usr/lib/libblas.dylib /usr/lib/liblapack.dylib :info:build libtool: link: /opt/local/bin/gfortran-mp-4.6 -dynamiclib -o .libs/libarpack.2.dylib -Wl,-force_load,./SRC/.libs/libarpacksrc.a -Wl,-force_load,./UTIL/.libs/libarpackutil.a -L/opt/local/lib -O2 -m64 -install_name /opt/local/lib/libarpack.2.dylib -compatibility_version 3 -current_version 3.0 -Wl,-single_module :info:build gfortran-mp-4.6: fatal error: no input files; unwilling to write output files The problem is due to this change: http://forge.scilab.org/index.php/p/arpack-ng/source/commit/b43a0eda6 f149b94deb6228765773566b3d73585/ If I revert the changes to Makefile.am and PARPACK/Makefile.am, it works again. I see no rationale listed there for the change. What is the purpose? Is it necessary? Is it supposed to entail some change to how the user builds? The configure line here is: :debug:configure Environment: CPATH='/opt/local/include' CFLAGS='-pipe -O2 -arch x86_64' CPPFLAGS='-I/opt/local/include' CXXFLAGS='-pipe -O2 -arch x86_64' LIBRARY_PATH='/opt/local/lib' MACOSX_DEPLOYMENT_TARGET='10.8' MPIF77='/opt/local/bin/mpif77' CXX='/usr/bin/clang++' CC_PRINT_OPTION\ S_FILE='/opt/local/var/macports/build/_Users_dstrubbe_Software_MacPor ts_math_arpack/arpack/work/.CC_PRINT_OPTIONS' F90FLAGS='-pipe -O2 -m64' LDFLAGS='-L/opt/local/lib -arch x86_64' FCFLAGS='-pipe -O2 -m64' OBJC='/usr/bin/clang' INSTALL='/usr/bin/install -c' OBJCFLAGS='-pipe -O2 -arch x\ 86_64' FFLAGS='-pipe -O2 -m64' F77='/opt/local/bin/gfortran-mp-4.6' CC_PRINT_OPTIONS='YES' CC='/usr/bin/clang' :debug:configure Assembled command: 'cd "/opt/local/var/macports/build/_Users_dstrubbe_Software_MacPorts _math_arpack/arpack/work/arpack-ng-3.1.3" && ./configure --prefix=/opt/local home=/opt/local/var/macports/build/_Users_dstrubbe_Software_MacPorts_ math_arpack/arpack/work/arpack-ng-3.\ 1.3 FFLAGS='-O2 -m64' LDFLAGS='-L/opt/local/lib' --enable-mpi --with-blas=/usr/lib/libblas.dylib --with-lapack=/usr/lib/liblapack.dylib' :debug:configure Executing command line: cd "/opt/local/var/macports/build/_Users_dstrubbe_Software_MacPorts _math_arpack/arpack/work/arpack-ng-3.1.3" && ./configure --prefix=/opt/local home=/opt/local/var/macports/build/_Users_dstrubbe_Software_MacPorts_ math_arpack/arpack/work/arpack-\ ng-3.1.3 FFLAGS='-O2 -m64' LDFLAGS='-L/opt/local/lib' --enable-mpi --with-blas=/usr/lib/libblas.dylib --with-lapack=/usr/lib/liblapack.dylib
Comment 1 by Jordi Gutiérrez Hermoso, Jun 7, 2013
I'm not sure this is relevant, but why is your configure line setting CFLAGS and CPPFLAGS but no FFLAGS? This is a Fortran program.
Comment 2 by David Strubbe, Jun 7, 2013
Actually, it does set FFLAGS='-pipe -O2 -m64' above. Some of the other stuff is just overall defaults in MacPorts.
Comment 3 by Jordi Gutiérrez Hermoso, Jun 7, 2013
Okay, well, the rationale for the offending changeset is mentioned in the commit message: to update libtool usage. ARPACK builds fine on my Debian system. The line that libtool runs for me is: libtool: link: gfortran -shared -fPIC -Wl,--whole-archive ./SRC/.libs/libarpacksrc.a ./UTIL/.libs/libarpackutil.a -Wl,--no-whole-archive -lblas -llapack -O2 -Wl,-soname -Wl,libarpack.so.2 -o .libs/libarpack.so.2.0.0 which does include the necesssary -o parameter. What libtool version are you using? I have 2.4.2 here. Note that if you're using a system libtool, it might be ancient, because Apple refuses to update GNU packages.
Comment 4 by David Strubbe, Jun 7, 2013
I am using libtool 2.4.2 from MacPorts. What I mean by asking for a rationale is, just because one can update it, does that mean there is some problem with the previous way? I can just apply a patch to undo the offending revision, but I wonder if there something better I should do. Do you use the same configure line for 3.1.2 and 3.1.3?
Comment 5 by Jordi Gutiérrez Hermoso, Jun 7, 2013
What is gfortran-mp-4.6, and how does it differ from gfortran? And yes, the autoconfiscation of arpack-ng previous to this change was incomplete. It was causing problems for us when creating tarballs. My configure line is just "./configure". It doesn't need all the extra cruft that you need on Mac OS X.
Comment 6 by Jordi Gutiérrez Hermoso, Jun 7, 2013
I just noticed that you're mixing clang with gfortran. While this shouldn't matter because there is no C here, is it somehow affecting the linking stage? Is gfortran-mp, whatever that is, used throughout for building and linking, or is clang getting in the way somewhere?
Comment 7 by David Strubbe, Jun 7, 2013
I tried earlier with gcc instead of clang and got the same result. gfortran-mp-4.6 = gfortran version 4.6, as provided by MacPorts. What do you mean by "autoconfiscation"?
Comment 8 by Jordi Gutiérrez Hermoso, Jun 7, 2013
http://en.wikipedia.org/wiki/Autoconfiscation What is gfortran-mp-4.6?
Comment 9 by Jordi Gutiérrez Hermoso, Jun 7, 2013
Oh, right, the mp is just "macports". I'm out of ideas. Revert that change if it fixes the problem for you, but that will create other problems for me. I have no idea why you're having this problem.
Comment 10 by David Strubbe, Jun 7, 2013
What was the problem with 'autoconfiscation' before?
Comment 11 by Jordi Gutiérrez Hermoso, Jun 10, 2013
An incomplete or incorrect autoconfiscation creates many problems. The one we were experiencing at the time was that cross-compiling wasn't working properly. Speaking of cross-compiling, do you happen to know if it's possible to compile for any Apple OS without ever clicking on an "I agree" button written by Apple? I would like to be able to cross-compile this for Mac OS X so that you don't have to.
Comment 12 by David Strubbe, Jun 10, 2013
Can you be more explicit? What do you mean by "incomplete" autoconfiscation? Anyway, if the issue is cross-compiling, then that has no significance to the MacPorts package, and I will just patch to undo the problematic change. What "I agree" button are you talking about? I am trying to create a MacPorts package anyway, which are basically all built from source. So, a cross-compiled version doesn't really help, I want the source to be able to build on this platform.
Comment 13 by Jordi Gutiérrez Hermoso, Jun 10, 2013
For example, when I started working on the build system, "make dist" wasn't working. I know that jwe's work was towards cross-compilation. I don't know if the only issue is cross-compilation. That was but one issue that we were attempting to fix. This "I agree" button: http://en.wikipedia.org/wiki/HumancentiPad In short, how it's impossible to build for Mac OS X without agreeing to the Xcode and/or the Apple Developer Network restrictive terms. If we didn't have those licensing restrictions, it would be much easier to create binaries for Mac OS X, so that macports wouldn't have to be that important. Users of free software on Mac OS X wouldn't have to compile the software themselves; people like us on GNU Octave could build it for them. It would be much easier to give them binaries. Think of all the CPU cycles we could save! Macports right now takes hours, sometimes days to compile GNU Octave for our users, just because Apple makes it difficult to play in their walled garden.
Comment 14 by David Strubbe, Jun 10, 2013
Could you give a serious answer about the "I agree" button, if you have a serious question? I am not sure what the reason MacPorts builds from source is, but I don't think it is related to licensing terms. I don't see what problem there is in distributing Mac binaries, there are plenty available for download.
Comment 15 by Jordi Gutiérrez Hermoso, Jun 10, 2013
It is a serious answer. Have you ever read anything that you've clicked "I agree" to from Apple? Do you know what you've agreed to?
Comment 16 by David Strubbe, Jun 10, 2013
A link to a South Park episode hardly seems serious. Why don't you specify what licensing terms you object to?
Comment 17 by Jordi Gutiérrez Hermoso, Jun 10, 2013
Parody can be quite serious. http://www.goodreads.com/quotes/14392-if-you-want-to-tell-people-the- truth-make-them I specifically object to clauses about agreeing to allow Apple to spy on you and clauses that forbid you from helping your neighbour. I have not read Apple legalese in a long time, so the terms may have changed since then. When you read it, you enjoyed the idea of being spied upon and clauses that said that you couldn't share with other people some fruits of your labour? This bug report is getting out of hand. If you want to continue this discussion about this part of the problem (i.e. Apple), we can continue over email, firstname.lastname@example.org As to the actual bug described here, can you please show me the gfortran linking line with and without the patch you identify as the offender?
Comment 18 by David Strubbe, Jun 11, 2013
Here is the link line with the patch. The one without is in my original post above. libtool: link: /opt/local/bin/gfortran-mp-4.6 -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libarpack.2.dylib -Wl,-force_load,./SRC/.libs/libarpacksrc.a -Wl,-force_load,./UTIL/.libs/libarpackutil.a -L/opt/local/lib -L/opt/local/lib/gcc46/gcc/x86_64-apple-darwin12/4.6.4 -L/opt/local/lib/gcc46/gcc/x86_64-apple-darwin12/4.6.4/../../.. /opt/local/lib/gcc46/libgfortran.dylib -L/opt/local/lib/gcc46 /opt/local/lib/gcc46/libquadmath.dylib -lm -O2 -m64 -install_name /opt/local/lib/libarpack.2.dylib -compatibility_version 3 -current_version 3.0 -Wl,-single_module
Comment 19 by Jordi Gutiérrez Hermoso, Jun 11, 2013
Can you try manually adding stuff to the failing line until you can figure out what gfortran wants here? I'm confused by the error message. I'm suspecting it might be a problem with ld on Mac OS X: http://koichitamura.blogspot.ca/2008/08/macpython-extension-dependenc y.html If you add Can you try manually adding stuff to the failing line until you can figure out what gfortran wants here? I'm confused by the error message. I'm suspecting it might be a problem with ld on Mac OS X: http://koichitamura.blogspot.ca/2008/08/macpython-extension-dependenc y.html If you add "-Wl,-undefined -Wl,dynamic_lookup" to the failing line, does it link correctly?
Comment 20 by David Strubbe, Jun 12, 2013
I found that this more minimal patch to Makefile.in makes it work, i.e. the lines about dummy.f are not relevant to the problem: -libarpack_la_LDFLAGS = -no-undefined -version-info 2:0 +libarpack_la_LDFLAGS = -version-info 2:0 libarpack_la_LIBADD = \ $(top_builddir)/SRC/libarpacksrc.la \ $(top_builddir)/UTIL/libarpackutil.la \ - $(BLAS_LIBS) $(LAPACK_LIBS) + $(BLAS_LIBS) $(LAPACK_LIBS) $(FLIBS) Adding "-Wl,-undefined -Wl,dynamic_lookup" does not work, I still get the message about no input files. If add $(FLIBS) but not "-Wl,undefined -Wl,dynamic_lookup", I get errors about undefined symbols. Rather than putting $(LIBS) in the link line, it seems like just about anything is ok, for example just "-lm". Also, I realize that we are discussing the same issue as http://forge.scilab.org/index.php/p/arpack-ng/issues/1195/
Comment 21 by David Strubbe, Jun 12, 2013
Ok, finding that putting anything with "-l" in the link line made it work helped me find a solution that does not require patching arpack. I tend to agree this is a bug in "ld"; it seems this is provided by MacPorts in /opt/local/bin/ld. Anyway, the solution is: make sure blas and lapack are specified to the configure script as --with-blas="-Wl,--start-group -L/usr/lib -lblas -Wl,--end-group" --with-lapack="-Wl,--start-group -L/usr/lib -llapack -Wl,--end-group" rather than --with-blas=/usr/lib/libblas.dylib --with-lapack=/usr/lib/liblapack.dylib (The -Wl,--start-group is required unfortunately to avoid confusion with ATLAS blas and lapack provided from MacPorts. This is using the built-in Accelerate libraries.) Or with ATLAS: --with-blas=-lsatlas instead of --with-blas=/opt/local/lib/libsatlas.dylib
Comment 22 by David Strubbe, Jun 12, 2013
Unfortunately I was premature. Only the atlas one above works, and still MPI gives unresolved symbols in PARPACK.
Comment 23 by David Strubbe, Jun 13, 2013
The workaround for +accelerate is to pass this redundant info to configure: LDFLAGS='/usr/lib/libblas.dylib /usr/lib/liblapack.dylib' --with-blas="-lblas -llapack" And, MPI works provided I set F77=mpif77. This was not necessary in version 3.1.2. Also I will point out that g95 no longer seems able to compile the project, since it will not accept -Wl,-force_load given by libtool at the linking stage. I have two general suggestions for the ARPACK-NG project based on my experience trying to solve this: a) configure macros should use Fortran for linking, not C, since C will not be used in the actual compilation; i.e. inserting AC_LANG([Fortran 77]) towards the beginning of configure.ac. b) offer some other Makefile targets than just "all": e.g. to build just arpack, or just parpack, or just libraries, or just examples, etc.
Comment 24 by David Strubbe, Jun 20, 2013
ARPACK 3.1.3 is now packaged in MacPorts, according to the discussion above. https://trac.macports.org/browser/trunk/dports/math/arpack/Portfile
Comment 25 by Sylvestre Ledru, Jun 20, 2013
David, anything would like us to apply upstream ?
Comment 26 by David Strubbe, Jun 20, 2013
Nothing required, just the suggestions above about AC_LANG and Makefile targets. Additionally, I think it would simplify matters if MPIF77 were removed everywhere in the build system in favor of F77. I am not sure what purpose it serves other than allowing for confusion if F77 and MPIF77 are not set consistently.
Comment 27 by claudia de grandi, Sep 21, 2013
Hello, despite following the discussion here above, I have trouble installing arpack on my Mac OS X 10.7.5. I have tried both the 3.1.2 and 3.1.3 version with partial success. With 3.1.2 the installation works fine, but when I try to compile the example in SIMPLE i get the error: make: *** No rule to make target `../../ARmake.inc'. Stop. which I found as a reported issue, but without a clear solution. When I tried with the 3.1.3 version at the installation stage i get the error: gfortran: no input files; unwilling to write output files make: *** [libarpack.la] Error 1 make: *** [all-recursive] Error 1 I have tried to revert the changes in Makefile.am and PARPACK/Makefile.am as suggested above, as well i have updated my macports. Not sure what is the best and easiest way to have either the 3.1.2 or the 3.1.3 version working. Any advice would be very much appreciated. Thank you! claudia
Comment 28 by David Strubbe, Sep 24, 2013
The easiest way probably is: use MacPorts to install arpack. (I don't know why you say you updated macports, because it seems like you aren't using it.) For 3.1.3, since the error you get is the same as the one I originally reported, probably the workaround I gave above (for LDFLAGS) will solve it. From your comments, it doesn't sound like you tried that.
Comment 29 by claudia de grandi, Sep 24, 2013
Thank you for your patience, this has been helpful, I finally was able to install the 3.1.3 version with macports.
Comment 30 by Sylvestre Ledru, Nov 6, 2013
Seems it is now fixed. Please reopen if it is not the case
Comment 32 by maxx luther, Sep 20, 2019
Best Messaging apps for android smartphones https://bestmessagingapps.blogspot.com
Comment 33 by smith seo, Oct 6, 2019
I really like this blog site, will definitely come back again. Make sure you carry on creating quality content articles. bæredygtig pension https://baeredygtig-pension.dk/
Comment 36 by Robin jack, Dec 1, 2019
Hi there, I must say that Tales from abroad » Blog Archive » Rafting is a extremely excellent place to slack from function I really really like your blog and I’ve already bookmarked it. Make sure you, maintain it up to date much more often. Thank you! casino online http://adserving.unibet.com/redirect.aspx?pid=301&bid=4200&re directURL=https://www.casinoreviews.casino/en/news/paddy-power-casino /no-deposit-bonus-code/906-claim-a-limited-time-no-deposit-bonus-at-p addy-power-casino
Comment 37 by Robin jack, Jan 1, 2020
You’ve really written a very good quality article here. Thank you very much best backlink service https://www.fiverr.com/afiabacklinks
Comment 38 by Robin jack, Feb 9, 2020
you should always keep your garden tools in low humidity area to prevent them from getting rusty*link building link building https://www.fiverr.com/afiabacklinks/do-high-domain-rating-dr-and-hig h-url-rating-ur-backlinks