Problem linking with gfortran v4.9.2 on OS X Yosemite: 'Undefined symbol "start"' problem

[Paul van Delst]

Hello,

I posted to the gfortran mailing list but haven't received a reply so I
thought I'd toss it out to the newsgroup to see if anyone had
encountered (and solved) this problem.

I installed gfortran 4.9.2 for Yosemite on my mac. The install was quick
and easy as always (Thanks FX!). Compilation works, but when I reach the
linking phase I get the following error:

Undefined symbols for architecture x86_64:
"start", referenced from:
-u command line option
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[1]: *** [build] Error 1
make: *** [all] Error 2

The version I have is:

$ gfortran --version
GNU Fortran (GCC) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.

Based on googling this problem, I also upgraded my version of Xcode
(v6.1.1) and updated the command line tools via the “Open Developer Tool
-> More Developer Tools” for OS X 10.10. (aside: isn't the “X” there
redundant?) I also ensured I have only one version of the Xcode app
installed. But still no joy.

Any info on how to get the Yosemite version of gfortran linking?

cheers,

paulv

[Louis Krupp]

Are you doing this through an IDE, or are you using a command line
that you could post?

Louis

[FX]

> Undefined symbols for architecture x86_64:
> "start", referenced from:
> -u command line option

Where is this -u option coming from? What is your compilation
command-line? What if you add "-v" to it, what does it output?

--
FX

[Damian Rouson]

You might instead try installing via Macports (www.macports.org). I've installed GCC 5.0 via Macports on Yosemite and have not encountered any problems since completing the installation.

Damian

[FX]

> You might instead try installing via Macports (www.macports.org). I've
> installed GCC 5.0 via Macports on Yosemite and have not encountered any
> problems since completing the installation.

I have nothing against suggesting alternatives to people, but the bug
here most probably doesn't lie with the compiler (many others, including
myself, work daily with this specific compiler/OS combination).

By suggesting one's favorite alternative when someone reports a problem,
I'm afraid that we give the impression that gfortran comes in 25
different flavors all with plenty of bugs, while the truth is that they
are 99.99% identical.

Moreover, installing an entirely new system (trying macports, homebrew,
fink, installer packages) to realize that they all give the same error is
really a waste of one's time :)

--
FX

[Damian Rouson]

On Saturday, January 10, 2015 at 7:31:08 PM UTC-8, FX wrote:
>
> Moreover, installing an entirely new system (trying macports, homebrew,
> fink, installer packages) to realize that they all give the same error is
> really a waste of one's time :)
>
> --
> FX

Comments like this are exactly why I largely abandoned c.l.f for a long time.

For what it's worth (apparently not much to you but possibly to some), I have seen linking problems related to the the installation method rather than the compiler itself. At least with a package installer, one can reasonably expect that the installation, including any necessary environment variables, is likely to be complete and correct, whereas with other installation methods, I've seen situations where the installation completes and yet errors not too dissimilar from the OP prevent compiling.

Damian

[FX]

> Comments like this are exactly why I largely abandoned c.l.f for a long
> time.

We'll have to agree to disagree, then. I find that people systematically
replying "install X instead of Y" to fellow users, when we clearly don't
have enough insight on the actual problem, clutter the discussion and
represent timewasting advice.

It also leads to some people googling for help and being confused about
what is "the right" version to use.

--
FX (that'll be my last post on the topic; too much would be meta
overload)

[paul.v...@noaa.gov]

Hello,

On Thursday, January 8, 2015 at 7:05:16 PM UTC-5, Louis Krupp wrote:
> On Thu, 08 Jan 2015 13:39:28 -0500, Paul van Delst
>

> >I installed gfortran 4.9.2 for Yosemite on my mac. The install was quick
> >and easy as always (Thanks FX!). Compilation works, but when I reach the
> >linking phase I get the following error:
> >
> >Undefined symbols for architecture x86_64:
> > "start", referenced from:
> > -u command line option
> >ld: symbol(s) not found for architecture x86_64
> >collect2: error: ld returned 1 exit status
> >make[1]: *** [build] Error 1
> >make: *** [all] Error 2
> >
> >The version I have is:
> >
> >$ gfortran --version
> >GNU Fortran (GCC) 4.9.2
> >Copyright (C) 2014 Free Software Foundation, Inc.
> >
> >Based on googling this problem, I also upgraded my version of Xcode
> >(v6.1.1) and updated the command line tools via the "Open Developer Tool
> >-> More Developer Tools" for OS X 10.10. (aside: isn't the "X" there
> >redundant?) I also ensured I have only one version of the Xcode app
> >installed. But still no joy.
> >
> >Any info on how to get the Yosemite version of gfortran linking?
>
> Are you doing this through an IDE, or are you using a command line
> that you could post?

A command line. I'm using a makefile (which hasn't changed for several years, worked on all the Big Cat OSX's and Mavericks).

Posting more info in reply to FX's post....

cheers,

paulv

[paul.v...@noaa.gov]

Hi FX,

The actual build target in my makefile looks like

build:: $(OBJ_FILES)
$(FL) $(OBJ_FILES) $(EXTRA_LDFLAGS) $(LDFLAGS) $(EXE_FILE) $(LIBS)

and the manifestation of that target looks like:

gfortran Type_Kinds.o File_Utility.o Message_Handler.o Test_Type_Kinds.o -o Test_Type_Kinds

so there is no "-u" option specified by me.

It was my understanding that this has something to do with Apple changing C library headers or somesuch in a non-standard way (waving hands here because I have no idea, basing comment on google search results).

As I mentioned in my original post, I have upgraded Xcode and verified it is the version for Yosemite (6.1.1). I also updated my command line tools via Xcode but I have not been able to determine if that was done correctly (how to get that build version number?). With Mavericks, the command line tools were installed via the app store - and the update section of that yields no updates so...I assume it's up-to-date.

I hope that's useful info.

cheers,

paulv

[paul.v...@noaa.gov]

On Friday, January 9, 2015 at 10:25:26 AM UTC-5, Damian Rouson wrote:
> You might instead try installing via Macports (www.macports.org). I've installed GCC 5.0 via Macports on Yosemite and have not encountered any problems since completing the installation.
>
> Damian

Hi Damian,

I don't want to start (or add to) an us-v.-them argument. I have used macports in the past (distant) for gcc (gfortran in particular) and the installer option provided by the Gfortran folks (in particular, FX) has always been the much much simpler path. The gfortran installs for the various big-cat OSX's and Mavericks have always worked (literally a 5minute effort, with most of that being the download time :o). This is the first time I have encountered a problem with gfortran-team-provided installation packages for Mac systems (that I can recall at least....searching clf may make a liar out of me, but even so it wasn't a show stopper since I'm still using them :o).

If the problem is in the provided installer, then my request for info should help with a fix. If the problem is due to something apple did to break third-party software builds/install, same deal. But the problem could very well be with my machine setup and, if I find out that is the case, I would like to fix it. (apple software and upgrade procedures have degraded over the years, and I'm not getting any smarter either :o)

cheers,

paulv

[Gordon Sande]

On the general issue of OsX funnies I had a curious one some time ago.

NAGware Fortran uses the C compiler with special flags. At some point
Apple did an internal upgrade from GCC to LLVM with Clang as the front end.
Suddenly my NAG Fortran was producing some curious diagnostics about
programming
forms that Clang flagged as questionable. It took some time for me to realize
that I could use a pass through option of NAG to have Clang suppress
all warnings.
Presto, no more diagnostics about questionable forms.

So the moral is that Clang is both much fussier on its notion of good style
(or avoiding some common trouble areas) in C as well as being a general
improvement
in compiler technology. I believe the principal authors of LLVM started at a
university and now reside at Apple. It is the basis of various language
projects
as well as their own Swift which is intended to replace Objective C.

[Louis Krupp]

On Mon, 12 Jan 2015 06:25:40 -0800 (PST), paul.v...@noaa.gov
wrote:

Would it be possible to add something to $LDFLAGS or $EXTRA_LDFLAGS to
trigger verbose output from the linker? (With gcc, that would be
-Wl,-v).

It occurs to me that if the "gfortran ..." line you posted came from
doing a verbose make, the $LIBS variable appears to be empty. This
might be at least part of the problem.

Louis

[Damian Rouson]

On Monday, January 12, 2015 at 6:43:34 AM UTC-8, paul.v...@noaa.gov wrote:
> On Friday, January 9, 2015 at 10:25:26 AM UTC-5, Damian Rouson wrote:
> > You might instead try installing via Macports (www.macports.org). I've installed GCC 5.0 via Macports on Yosemite and have not encountered any problems since completing the installation.
> >
> > Damian
>
> Hi Damian,
>
> I don't want to start (or add to) an us-v.-them argument. I have used macports in the past (distant) for gcc (gfortran in particular) and the installer option provided by the Gfortran folks (in particular, FX) has always been the much much simpler path. The gfortran installs for the various big-cat OSX's and Mavericks have always worked (literally a 5minute effort, with most of that being the download time :o). This is the first time I have encountered a problem with gfortran-team-provided installation packages for Mac systems (that I can recall at least....searching clf may make a liar out of me, but even so it wasn't a show stopper since I'm still using them :o).
>

Thanks for this explanation. Now I understand FX's response a lot better and I see that I launched an us-vs-them argument. I hadn't intended that even though it's an obvious conclusion from my suggestion. Your response and game plan make perfect sense.

Damian

[FX]

>> What if you add "-v" to it, what does it output?
>

> gfortran Type_Kinds.o File_Utility.o Message_Handler.o Test_Type_Kinds.o -o Test_Type_Kinds
> so there is no "-u" option specified by me.

Can you re-run that command line with -v added, so I can check where the
-u comes from?

--
FX

[paul.v...@noaa.gov]

Hi FX,

Sorry for the long wait, but I've been having problems replying in groups.

Anyhoo, below is the output. I do have a question beforehand though - I noticed that the OS X 10.10 link is now active again on your webpage, coudert.name. There was a time between when you announced it and now when it was not visible. I downloaded my version when the link was *not* visible, I just cut-and-pasted the URL from one of your announcement emails.

Has anything changed in the build on your website in the last month or so? If so, I can re-download and try again. If not, keep reading for the "-v" output

And here it is.... (I don't see any "-u" other than in the error message):


hootmanhat:/Users/paul/work/CRTM/trunk/test/Utility/Type_Kinds : gfortran Type_Kinds.o File_Utility.o Message_Handler.o Test_Type_Kinds.o -v -o Test_Type_Kinds

Driving: gfortran -mmacosx-version-min=10.10.0 Type_Kinds.o File_Utility.o Message_Handler.o Test_Type_Kinds.o -v -o Test_Type_Kinds -l gfortran -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin14/4.9.2/lto-wrapper
Target: x86_64-apple-darwin14
Configured with: ../gcc-4.9.2/configure --prefix=/usr/local/gfortran --with-gmp=/opt/gcc-4.8 --enable-languages=c,c++,fortran,objc,obj-c++ --build=x86_64-apple-darwin14
Thread model: posix
gcc version 4.9.2 (GCC)
Reading specs from /usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/4.9.2/../../../libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.10.0' '-v' '-o' 'Test_Type_Kinds' '-shared-libgcc' '-mtune=core2'
COMPILER_PATH=/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin14/4.9.2/:/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin14/4.9.2/:/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin14/:/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/4.9.2/:/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/
LIBRARY_PATH=/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/4.9.2/:/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/4.9.2/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.10.0' '-v' '-o' 'Test_Type_Kinds' '-shared-libgcc' '-mtune=core2'
/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin14/4.9.2/collect2 -dynamic -arch x86_64 -macosx_version_min 10.10.0 -weak_reference_mismatches non-weak -o Test_Type_Kinds -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/4.9.2 -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/4.9.2/../../.. Type_Kinds.o File_Utility.o Message_Handler.o Test_Type_Kinds.o -lgfortran -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5 -lgcc -lSystem -v
collect2 version 4.9.2
/opt/local/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.10.0 -weak_reference_mismatches non-weak -o Test_Type_Kinds -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/4.9.2 -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/4.9.2/../../.. Type_Kinds.o File_Utility.o Message_Handler.o Test_Type_Kinds.o -lgfortran -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5 -lgcc -lSystem -v
@(#)PROGRAM:ld PROJECT:ld64-134.9
configured to support archs: i386 x86_64
Library search paths:
/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/4.9.2
/usr/local/gfortran/lib
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/

Undefined symbols for architecture x86_64:
"start", referenced from:
-u command line option

[FX]

> Anyhoo, below is the output. I do have a question beforehand though - I
> noticed that the OS X 10.10 link is now active again on your webpage,
> coudert.name. There was a time between when you announced it and now
> when it was not visible. I downloaded my version when the link was
> *not* visible, I just cut-and-pasted the URL from one of your
> announcement emails.

The package itself hasn't changed since the announcement. At some point,
I inadvertently reverted my webpage (the HTML) back to an earlier state,
and I didn't notice until someone sent me an email about it. The software
packages were not affected.

> And here it is.... (I don't see any "-u" other than in the error
> message)

[snip]
> @(#)PROGRAM:ld PROJECT:ld64-134.9

That one is too old to be Yosemite (10.10) developer tools. You should
have:

- Xcode 6.1.1 (6A2008a)
- ld64-241.9 (from "ld -v")
- cctools-862 (from "as -v")
- Apple LLVM version 6.0 (clang-600.0.56) (from "cc -v")

That probably explains the issue you are experiencing. Update your dev
tools to the appropriate Yosemite combination. Use xcode-select to do
that; some tutorials are available e.g. there:
http://railsapps.github.io/xcode-command-line-tools.html

--
FX

[paul.v...@noaa.gov]

On Sunday, January 25, 2015 at 1:04:42 PM UTC-5, FX wrote:
> > Anyhoo, below is the output. I do have a question beforehand though - I
> > noticed that the OS X 10.10 link is now active again on your webpage,
> > coudert.name. There was a time between when you announced it and now
> > when it was not visible. I downloaded my version when the link was
> > *not* visible, I just cut-and-pasted the URL from one of your
> > announcement emails.
>
> The package itself hasn't changed since the announcement. At some point,
> I inadvertently reverted my webpage (the HTML) back to an earlier state,
> and I didn't notice until someone sent me an email about it. The software
> packages were not affected.
>
> > And here it is.... (I don't see any "-u" other than in the error
> > message)
> [snip]
> > @(#)PROGRAM:ld PROJECT:ld64-134.9
>
> That one is too old to be Yosemite (10.10) developer tools. You should
> have:
>
> - Xcode 6.1.1 (6A2008a)
> - ld64-241.9 (from "ld -v")
> - cctools-862 (from "as -v")
> - Apple LLVM version 6.0 (clang-600.0.56) (from "cc -v")

Hi again,

Thanks very much. I have:

- Xcode 6.1.1 (6A2008a)
- ld64-134.9
- cctools-836

- Apple LLVM version 6.0 (clang-600.0.56)

It is, as I sort of suspected, that the command line tools were not correctly updated when I upgraded Xcode.

The problem now is my mac doesn't think anything is wrong:
$ xcode-select --install
$ xcode-select: error: command line tools are already installed, use "Software Update" to install updates

Using "Software Update" tells me everything is up-to-date. Argh.

> That probably explains the issue you are experiencing. Update your dev
> tools to the appropriate Yosemite combination. Use xcode-select to do
> that; some tutorials are available e.g. there:
> http://railsapps.github.io/xcode-command-line-tools.html

Thanks very much again. I appreciate your help identifying my problem (especially on a Sunday!). I knew it was an Apple issue -- either direct via their changes, or indirect via their constantly bloody changing installation procedures.

cheers,

paulv

>
> --
> FX

[FX]

> The problem now is my mac doesn't think anything is wrong:
> $ xcode-select --install
> $ xcode-select: error: command line tools are already installed, use "Software Update" to install updates

So you've got the right Xcode and compiler, but somehow your linker and
assembler are old versions? That's weird.

$ xcode-select -p
/Applications/Xcode.app/Contents/Developer

If you get a different directory, you may try using option "-r".

--
FX

[paul.v...@noaa.gov]

On Sunday, January 25, 2015 at 2:52:35 PM UTC-5, FX wrote:
> > The problem now is my mac doesn't think anything is wrong:
> > $ xcode-select --install
> > $ xcode-select: error: command line tools are already installed, use "Software Update" to install updates
>
> So you've got the right Xcode and compiler, but somehow your linker and
> assembler are old versions? That's weird.

It is weird.

> $ xcode-select -p
> /Applications/Xcode.app/Contents/Developer
>
> If you get a different directory, you may try using option "-r".

I got

$ xcode-select -p
/Library/Developer/CommandLineTools

Wha...? :o)

Anyhow, now that I knew for sure there was funkiness with my command line tools, I reinstalled them again (for 10.10).

Same problem.

By doing something I should have done first time (if I knew what the problem was), I founwe

$ which ld
/opt/local/bin/ld

WTH?!? Where did that come from? An old macports installation? So I uninstalled macports (sudo port -fp uninstall installed) and deleteted /opt/local.

I then opened a new bash shell and got:

$ xcode-select -p
/Applications/Xcode.app/Contents/Developer

Excellent. Also:

$ which ld
/usr/bin/ld

$ ld -v
@(#)PROGRAM:ld PROJECT:ld64-241.9
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7m armv7em
LTO support using: LLVM version 3.5svn

Woohoo! New version!!

I then went to my unit test directory and recompiled:

$ make
OS type detected: Darwin
gfortran -c -fbounds-check -fimplicit-none -fconvert=big-endian -ffpe-trap=overflow,zero,invalid -ffree-form -fno-second-underscore -frecord-marker=4 -fbacktrace -ggdb -static -Wall -std=f2003 Type_Kinds.fpp
...etc...
gfortran -c -fbounds-check -fimplicit-none -fconvert=big-endian -ffpe-trap=overflow,zero,invalid -ffree-form -fno-second-underscore -frecord-marker=4 -fbacktrace -ggdb -static -Wall -std=f2003 Test_Type_Kinds.f90

gfortran Type_Kinds.o File_Utility.o Message_Handler.o Test_Type_Kinds.o -o Test_Type_Kinds

No link errors!! And the program ran just fine.

Your direction regarding the command line tools was the key point. So thanks a LOT. I have a software delivery of my own due end of month and you've just made my life so so so much easier. Beer's are on me next time I make it to Paris. :o)

cheers,

paulv

[Paul van Delst]

Hello,

Just wanted to report that after upgrading my laptop to Yosemite as
well, and verifying the Xcode and command line utilities update per
FX's earlier post, the gfortran install for OS X 10.10 was literally a 1
minute effort. Compilation, linking and running with no problems.

Just to get late-comers to this thread up to speed for the record, the
problem that lead to me posting was with my system (old version of Xcode
command line utilities lurking in my path) NOT in the gfortran installer
provided by FX.

Thanks,

paulv

[Beliavsky]

On Sunday, January 11, 2015 at 2:55:52 AM UTC-5, Damian Rouson wrote:
> On Saturday, January 10, 2015 at 7:31:08 PM UTC-8, FX wrote:
> >
> > Moreover, installing an entirely new system (trying macports, homebrew,
> > fink, installer packages) to realize that they all give the same error is
> > really a waste of one's time :)
> >
> > --
> > FX
>
> Comments like this are exactly why I largely abandoned c.l.f for a long time.

Comp.lang.fortran is actually less "colorful" than it used to be. There is of course spam, which Google Groups has recently been good at filtering out (for those who use that interface). But in the past, there were a few posters who were knowledgeable about Fortran and posted some useful information (especially if you used their favored compilers) but who were also off their rockers.

[FX]

> Just wanted to report that after upgrading my laptop to Yosemite as
> well, and verifying the Xcode and command line utilities update per
> FX's earlier post, the gfortran install for OS X 10.10 was literally a
> 1 minute effort. Compilation, linking and running with no problems.

Thanks for the earlier praise, and this clarification.

The gfortran/gcc/g++ packages I provide at http://coudert.name/ are
standalone installers for all Mac OS versions (Yosemite, Mavericks,
Mountain Lion, Lion and even earlier). They all install and run without
trouble on the latest version of each OS (minor updates) and matching
developer tools (Xcode and command-line tools, as available from Apple).

I will continue to package newer releases (newer GCC versions and newer
Apple OS).

--
FX

[mad...@gmail.com]

Hi all,

I have a similar problem using command line to compile Fortran codes in OS X El Capitan, and I have followed the methods in this post. But after I update xcode, install command line tools and uninstall macports, the problem is still there. I tried with both f77 and gfortran.

The version of f77 is
~/Documents/autovp $f77 -v
/usr/local/bin/f77 script based on f2c:
f2c (Fortran to C Translator) version 20100827.

With f77, I get the following error:

f77 autofit.o ew_finder.o smooth.o fitregion.o model.o combine.o fitsat.o inparam.o readdata.o polyfit.o -o autofit

Undefined symbols for architecture x86_64:

"MAIN__", referenced from:
-u command line option
(maybe you meant: _MAIN__)

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)
f77 minfit.o minimize.o model.o ew_finder.o oneparmin.o tossline.o splitreg.o readdata.o initparm.o fixparm.o loadline.o funcs.o nparmin.o inparam.o polyfit.o piksrt.o piksr2.o addline.o getlines.o -o minfit

Undefined symbols for architecture x86_64:

"MAIN__", referenced from:
-u command line option
(maybe you meant: _MAIN__)
"_doublet2_", referenced from:
_MAIN__ in minfit.o

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

My gfortran version is 5.2.0:

~/Documents/autovp $gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin14/5.2.0/lto-wrapper
Target: x86_64-apple-darwin14
Configured with: ../gcc-5.2.0/configure --prefix=/usr/local/gfortran --with-gmp=/Users/fx/devel/gcc/deps-static/x86_64 --enable-languages=c,c++,fortran,objc,obj-c++ --build=x86_64-apple-darwin14
Thread model: posix
gcc version 5.2.0 (GCC)

With gfortran -v, I get the following error:

f77 -c -o autofit.o autofit.f
autofit.f:
MAIN autofit:
Warning on line 34 of autofit.f: local variable gamma never used
Warning on line 34 of autofit.f: local variable ion_str never used
fappend:
f77 -c -o ew_finder.o ew_finder.f
ew_finder.f:
ew_finder:
Warning on line 123 of ew_finder.f: local variable id never used
f77 -c -o smooth.o smooth.f
smooth.f:
smooth:
smoothsat:
f77 -c -o fitregion.o fitregion.f
fitregion.f:
fitregion:
Warning on line 78 of fitregion.f: local variable lineflag never used
findmin:
fitline:
modelbelow:
f77 -c -o model.o model.f
model.f:
model:
model1:
cpf12:
f77 -c -o combine.o combine.f
combine.f:
combine:
Warning on line 57 of combine.f: local variable nl never used
f77 -c -o fitsat.o fitsat.f
fitsat.f:
fitsat:
Warning on line 50 of fitsat.f: local variable j never used
nhitest:
chisqr:
deconv:
Warning on line 169 of fitsat.f: local variable smallflux never used
Warning on line 169 of fitsat.f: local variable bigflux never used
f77 -c -o inparam.o inparam.f
inparam.f:
inparam:
f77 -c -o readdata.o readdata.f
readdata.f:
readdata:
Warning on line 57 of readdata.f: local variable k never used
len1:
f77 -c -o polyfit.o polyfit.f
polyfit.f:
polyfit:
Warning on line 88 of polyfit.f: local variable chisqold never used
Warning on line 88 of polyfit.f: local variable dvel never used
Warning on line 88 of polyfit.f: local variable hilim never used
Warning on line 88 of polyfit.f: local variable dwave never used
Warning on line 88 of polyfit.f: local variable nwrap never used
Warning on line 88 of polyfit.f: local variable sigmax never used
Warning on line 88 of polyfit.f: local variable lowlim never used
Warning on line 88 of polyfit.f: local variable fluxmax never used
funcpoly:
svdfit:
svdcmp:
svbksb:
/usr/local/gfortran/bin/gfortran -v autofit.o ew_finder.o smooth.o fitregion.o model.o combine.o fitsat.o inparam.o readdata.o polyfit.o -o autofit
Driving: /usr/local/gfortran/bin/gfortran -mmacosx-version-min=10.11.0 -v autofit.o ew_finder.o smooth.o fitregion.o model.o combine.o fitsat.o inparam.o readdata.o polyfit.o -o autofit -l gfortran -shared-libgcc
Using built-in specs.
COLLECT_GCC=/usr/local/gfortran/bin/gfortran
COLLECT_LTO_WRAPPER=/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin14/5.2.0/lto-wrapper
Target: x86_64-apple-darwin14
Configured with: ../gcc-5.2.0/configure --prefix=/usr/local/gfortran --with-gmp=/Users/fx/devel/gcc/deps-static/x86_64 --enable-languages=c,c++,fortran,objc,obj-c++ --build=x86_64-apple-darwin14
Thread model: posix
gcc version 5.2.0 (GCC)
Reading specs from /usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/5.2.0/../../../libgfortran.spec

rename spec lib to liborig

COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.11.0' '-v' '-o' 'autofit' '-shared-libgcc' '-mtune=core2'
COMPILER_PATH=/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin14/5.2.0/:/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin14/5.2.0/:/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin14/:/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/5.2.0/:/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/
LIBRARY_PATH=/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/5.2.0/:/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/5.2.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.11.0' '-v' '-o' 'autofit' '-shared-libgcc' '-mtune=core2'
/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin14/5.2.0/collect2 -dynamic -arch x86_64 -macosx_version_min 10.11.0 -weak_reference_mismatches non-weak -o autofit -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/5.2.0 -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/5.2.0/../../.. autofit.o ew_finder.o smooth.o fitregion.o model.o combine.o fitsat.o inparam.o readdata.o polyfit.o -lgfortran -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5 -lgcc -lSystem -v
collect2 version 5.2.0
/usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.11.0 -weak_reference_mismatches non-weak -o autofit -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/5.2.0 -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/5.2.0/../../.. autofit.o ew_finder.o smooth.o fitregion.o model.o combine.o fitsat.o inparam.o readdata.o polyfit.o -lgfortran -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5 -lgcc -lSystem -v
@(#)PROGRAM:ld PROJECT:ld64-253.6
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)
Library search paths:
/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/5.2.0

/usr/local/gfortran/lib
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/

Undefined symbols for architecture x86_64:

"_d_lg10", referenced from:
_nhitest_ in fitsat.o
"_d_sign", referenced from:
_svdcmp_ in polyfit.o
"_do_fio", referenced from:
_MAIN__ in autofit.o
_ew_finder__ in ew_finder.o
_fitregion_ in fitregion.o
_deconv_ in fitsat.o
_readdata_ in readdata.o
"_do_lio", referenced from:
_model1_ in model.o
_combine_ in combine.o
_inparam_ in inparam.o
_readdata_ in readdata.o
_svdcmp_ in polyfit.o
"_e_rsfe", referenced from:
_readdata_ in readdata.o
"_e_rsle", referenced from:
_inparam_ in inparam.o
_readdata_ in readdata.o
"_e_wsfe", referenced from:
_MAIN__ in autofit.o
_ew_finder__ in ew_finder.o
_fitregion_ in fitregion.o
_deconv_ in fitsat.o
_readdata_ in readdata.o
"_e_wsle", referenced from:
_model1_ in model.o
_combine_ in combine.o
_readdata_ in readdata.o
_svdcmp_ in polyfit.o
"_f_clos", referenced from:
_MAIN__ in autofit.o
_ew_finder__ in ew_finder.o
_inparam_ in inparam.o
_readdata_ in readdata.o
"_f_open", referenced from:
_MAIN__ in autofit.o
_ew_finder__ in ew_finder.o
_inparam_ in inparam.o
_readdata_ in readdata.o
"_getarg_", referenced from:
_MAIN__ in autofit.o
"_i_len", referenced from:
_fappend_ in autofit.o
"_main", referenced from:
implicit entry/start for main executable
"_pow_dd", referenced from:
_nhitest_ in fitsat.o
"_pow_di", referenced from:
_polyfit_ in polyfit.o
"_s_cat", referenced from:
_fappend_ in autofit.o
"_s_cmp", referenced from:
_fappend_ in autofit.o
_readdata_ in readdata.o
"_s_copy", referenced from:
_fappend_ in autofit.o
"_s_rsfe", referenced from:
_readdata_ in readdata.o
"_s_rsle", referenced from:
_inparam_ in inparam.o
_readdata_ in readdata.o
"_s_stop", referenced from:
_MAIN__ in autofit.o
"_s_wsfe", referenced from:
_MAIN__ in autofit.o
_ew_finder__ in ew_finder.o
_fitregion_ in fitregion.o
_deconv_ in fitsat.o
_readdata_ in readdata.o
"_s_wsle", referenced from:
_model1_ in model.o
_combine_ in combine.o
_readdata_ in readdata.o
_svdcmp_ in polyfit.o

ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

make: *** [autofit] Error 1

Other settings of mine are:

- Mac OS X El Capitan 10.11.1
- Xcode 7.1
- ld64-253.6 (from "ld -v")
- Apple LLVM version 7.0.0 (clang-700.1.76) (from "cc -v")

When I type "as -v", it stuck by showing:

Apple LLVM version 7.0.0 (clang-700.1.76)
Target: x86_64-apple-darwin15.0.0
Thread model: posix
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1as -triple x86_64-apple-macosx10.11.0 -filetype obj -main-file-name - -target-cpu core2 -fdebug-compilation-dir /Users/madcpf/Documents/autovp -dwarf-debug-producer Apple LLVM version 7.0.0 (clang-700.1.76) -o a.out -

Does anyone have any suggestions about how to solve this problem?

Thank you so much!
Pengfei


在 2015年1月26日星期一 UTC-8下午4:50:36，FX写道：

[FX]

> I have a similar problem using command line to compile Fortran codes in
> OS X El Capitan

On Mac OS X El Capitan:

1. Install Xcode 7.1 and command line tools
2. Download the gfortran 5.2 installer for Yosemite and El Capitan
at http://coudert.name/software.html
3. Install it.
4. Compile with command "gfortran", which is now in your PATH (it is in
/usr/local/bin/gfortran)

> With gfortran -v, I get the following error:

The errors you quote were not obtained by running gfortran, as they do
not follow the gfortran warning/error format. Make sure you compile with
the actual gfortran compiler.

If you are getting "undefined symbol" errors, it means you have not
compiled the source code it its entirety, or you forgot to link it to
some dependecy (external library, shared or dynamic).

--
FX