Issue 1220: v3.1.3 build fails for MacPorts

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[1]: Entering directory 
: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 -rpath /opt/local/lib  
./SRC/ ./UTIL/ /usr/lib/libblas.dylib 
:info:build libtool: link: /opt/local/bin/gfortran-mp-4.6 
-dynamiclib  -o .libs/libarpack.2.dylib   
-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:

If I revert the changes to and PARPACK/, 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\
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 
_math_arpack/arpack/work/arpack-ng-3.1.3" && 
./configure --prefix=/opt/local 
1.3 FFLAGS='-O2 -m64' LDFLAGS='-L/opt/local/lib' --enable-mpi 
:debug:configure Executing command line:  cd 
_math_arpack/arpack/work/arpack-ng-3.1.3" && 
./configure --prefix=/opt/local 
ng-3.1.3 FFLAGS='-O2 -m64' LDFLAGS='-L/opt/local/lib' --enable-mpi 

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, -o .libs/

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 

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

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" 

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 

This "I agree" button:

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 

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.

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,

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 

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,./UTIL/.libs/libarpackutil.a  -L/opt/local/lib 
/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:

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:

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 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/ \
        $(top_builddir)/UTIL/ \

Adding "-Wl,-undefined -Wl,dynamic_lookup" does not work, 
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

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


(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 

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 

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
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.

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


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 `../../'. 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[1]: *** [] Error 1
make: *** [all-recursive] Error 1

I have tried to revert the changes in and 
PARPACK/ as suggested above, as well i have updated my 

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!


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
Status: Fixed

Comment 31 by Robin jack, Sep 17, 2019

sugarlove pays out

Comment 32 by maxx luther, Sep 20, 2019

Best Messaging apps for android smartphones

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

Comment 34 by Robin jack, Oct 21, 2019

메이저사이트 추천

Comment 35 by Robin jack, Nov 4, 2019


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

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

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

Created: 7 years 2 months ago by David Strubbe

Updated: 6 months 3 days ago

Status: Fixed

Followed by: 6 persons


This issue is related to
1195 - Problems building julia

This issue is duplicated by
1226 - build fails on OS X