Gildas Install Fail

[jtb1435@…]

I am trying to install Gildas on my computer (OSX Mountain Lion) after having installed MacPorts for the first time. When I try to install Gildas, it keeps coming up with the same error message (below). I've tried 'sudo port clean' and re installing as was suggested in ticket:50543, but it hasn't had any effect.

--->  Computing dependencies for gildas
--->  Fetching archive for gildas
--->  Attempting to fetch gildas-201606a_0+gcc5.darwin_12.x86_64.tbz2 from https://packages.macports.org/gildas
--->  Attempting to fetch gildas-201606a_0+gcc5.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/gildas
--->  Attempting to fetch gildas-201606a_0+gcc5.darwin_12.x86_64.tbz2 from http://sea.us.packages.macports.org/macports/packages/gildas
--->  Fetching distfiles for gildas
--->  Verifying checksums for gildas
--->  Extracting gildas
--->  Applying patches to gildas
--->  Configuring gildas
--->  Building gildas
Error: org.macports.build for port gildas returned: command execution failed
Please see the log file for port gildas for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gildas/gildas/main.log

The main.log file is attached below, but I can't figure out what is causing it to hang up.

[mf2k (Frank Schima)]

In the future, please use WikiFormatting and Cc the port maintainers (port info --maintainers gildas), if any.

[mf2k (Frank Schima)]

Opps. I see you tried to use WikiFormatting. Note that there is a preview button.

[smaret (Sebastien Maret)]

This is a link error:

(cd ./built/x86_64-darwin-gfortran && /opt/local/bin/gfortran-mp-5  -dynamiclib   -L/opt/local/lib -Wl,-headerpad_max_install_names -shared -o /opt/local/lib/gildas/x86_64-darwin-gfortran/lib/libatm2009.so -install_name /opt/local/lib/gildas/x86_64-darwin-gfortran/lib/libatm2009.so ATMOpacity.o ATMLength.o ATMInverseLength.o ATMPressure.o ATMTemperature.o ATMAngle.o ATMFrequency.o ATMHumidity.o ATMMassDensity.o ATMNumberDensity.o ATMPercent.o ATMWaterVaporRadiometer.o ATMWVRMeasurement.o ATMType.o ATMProfile.o ATMRefractiveIndex.o ATMRefractiveIndexProfile.o ATMSkyStatus.o ATMSpectralGrid.o ATMError.o   \
2583	:info:build     -o /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gildas/gildas/work/gildas-src-jun16a/integ/x86_64-darwin-gfortran/lib/libatm2009.so -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gildas/gildas/work/gildas-src-jun16a/integ/x86_64-darwin-gfortran/lib -L/opt/local/lib -L/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib -L/System/Library/Frameworks/Accelerate.framework/Frameworks/vecLib.framework/Versions/Current/  -lc++  -lm -ldl -install_name @loader_path/../lib/libatm2009.so)
Undefined symbols for architecture x86_64:
"std::basic_string<char, std::char_traits<char>, std::allocator<char> >::compare(char const*) const", referenced from:
atm::Opacity::Opacity(double, std::basic_string<char, std::char_traits<char>, std::allocator<char> >) in ATMOpacity.o

I don't have a computer with Mountain Lion installed, so I can't reproduce this error (which does not occur on El Capitain). What is the output of the following commands?

which g++
g++ --version

[jtb1435@…]

Output of the first:

/usr/bin/g++

And the second:

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.6.0
Thread model: posix

[bardeau]

Hi! What do the following commands return?

sudo port select gcc
which gcc
which g++
which gfortran

[jtb1435@…]

sudo port select gcc
Available versions for gcc:
	llvm-gcc42
	mp-gcc5
	none (active)

which gcc
/usr/bin/gcc

which g++
/usr/bin/g++

Then 'which gfortran' yields no results. It skips to the next line.

[bardeau]

Ok, thanks for the feedback. As far as I can see the objects files are constructed with the default g++, with a typical command line:

g++  -c  foo.cpp -o foo.o

This is correct. Then the linker complains about "Undefined symbols for architecture x86_64", but it is unclear to if the symbols are not found or if the architecture x86_64 is missing. Can you please create a test file (test.cpp) with those lines:

int main()
{
  int a;
  a = 1;
}

Compile it:

g++ -c test.cpp

And check the contents of the resulting object file:

file test.o

and let us know the output of the command above?

[jtb1435@…]

I tried creating the test file, but as I've never worked with C++ before, it came up with an error when I tried to compile it.

test.cpp:1:1: error: expected unqualified-id
{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf400
^
1 error generated.

I don't know if this is an error on my part writing test.cpp or it relates to my original issue.

EDIT: I got it working and the output was

test.o: Mach-O 64-bit object x86_64

[bardeau]

Ok. So that's really a symbol issue. That's hard to debug without having access to an identical machine and reproducing the bug. I see several options, from easiest to more complicated:

1) Use the MacPorts compilers, i.e. sudo port select gcc mp-gcc5 This will change gcc and g++ from Apple LLVM ones to MacPorts ones. This can be a problem for other software if they were relying precisely on the Apple compilers. Note that this does not solve the issue, this circumvents it by using another configuration. Once the compilers are changed, you should rebuild gildas from scratch.

2) Update the Apple compilers. You have Apple LLVM version 5.1 (clang-503.0.38), but I have 6.1. Compilers can be updated by updating Xcode ( ​https://developer.apple.com/support/xcode/ ). However there is no guarantee this solves the issue.

3) Compile Gildas "by hand" (see ​http://www.iram.fr/~gildas/dist/gildas.README section IV.2). The bug won't disappear but we will will able to make some tests and iterate together.

As you prefer!

[ryandesign (Ryan Carsten Schmidt)]

Replying to jtb1435@…:

I tried creating the test file, but as I've never worked with C++ before, it came up with an error when I tried to compile it.

test.cpp:1:1: error: expected unqualified-id
{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf400
^
1 error generated.

I don't know if this is an error on my part writing test.cpp or it relates to my original issue.

You saved the file as an RTF file, perhaps using TextEdit; its default mode is to save RTF files. You need to save as a text file instead. If you want to use TextEdit for this, you can choose Make Plain Text from the Format menu. You can also make text files the default in the TextEdit preferences window, if you like.

This ticket is a duplicate of #46349.

The fact that sudo port select gcc ... affects gildas is a bug in the gildas port. I've filed a new bug report for that: #51741.

[bardeau]

As far as I can say this bug is not fixed (no answer from comment #10).

I strongly suspect this is linked to this issue I raised a few months ago: ​https://forums.developer.apple.com/message/88953 Basically, Apple LLVM clang++ is not able to tell where/what is the library to be used for linking. No better choice than making assumptions.

[jtb1435@…]

As you can see in comment 9, I did get the RTF file issue sorted. But thank you for the information.

Option 1) was unsuccessful as of yesterday afternoon. The installation of gildas stalled at building the port. I hope to try it again. Option 2) I can only upgrade to 5.1.1 with my operating system, so I have done that and will see if it has any effect.

So, no this bug is not fixed yet.

[smaret (Sebastien Maret)]

It seems that this bug is different from #46349, so I am re-opening it.

[smaret (Sebastien Maret)]

I've just committed a new version (r149944) that also address some issue with the compiler selection (see #51741). Would you mind running port selfupdate and try to build gildas again to see if this bug is still present?

[jtb1435@…]

It seems I am unable to get past the selfupdate.

port -v selfupdate
--->  Updating MacPorts base sources using rsync
receiving file list ... done
rsync: mkstemp "/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/.base.tar.SYlMnM" failed: Permission denied (13)
inflate returned -3 (19 bytes)
rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-42/rsync/token.c(419) [receiver=2.6.9]
rsync: connection unexpectedly closed (31 bytes received so far) [generator]
rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-42/rsync/io.c(452) [generator=2.6.9]
Command failed: /usr/bin/rsync -rtzv --delete-after rsync://rsync.macports.org/release/tarballs/base.tar /opt/local/var/macports/sources/rsync.macports.org/release/tarballs
Exit code: 12
Error: Error synchronizing MacPorts sources: command execution failed
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing MacPorts sources: command execution failed

[mf2k (Frank Schima)]

See wiki:FAQ#selfupdatefails.

[jtb1435@…]

Thanks. updated successfully. However 'sudo port install gildas' still fails.

[mf2k (Frank Schima)]

Please attach the new main.log file.

[jtb1435@…]

Updated error file

[mf2k (Frank Schima)]

That log shows a successful install of libedit. Please clean and try again and attach the new main.log file for gildas.

[jtb1435@…]

Well, in the past week I have continued working on installing Gildas to my laptop with no luck.

However, I don't believe the problem is there anymore. I recently received a newer laptop (OSX 10.11) and after waiting overnight for the install to process, was successful. It seems the (latest) problem was in my old computer's inability to handle the long install process without overheating or freezing. Given enough time, it may have been able to.

So thank you all for your help in sorting this out.

[ryandesign (Ryan Carsten Schmidt)]

This is basically the same as #59753 now.

Back when this ticket was filed, MacPorts used the same default C++ stdlib as Apple, which meant that on 10.8 and earlier we used libstdc++. But gildas has its build system hardcoded to use -lc++ when linking something that was built with clang++, which would have been the wrong decision on 10.8 and earlier back then. clang++ would have built stuff using libstdc++, and then when it came time to link, gildas would try to link that with libc++, which couldn't possibly work.

But now MacPorts 2.6.0 has been released, in which we changed the default C++ stdlib for 10.6-10.8 from libstdc++ to libc++ for better compatibility with newer software requiring C++11 and later. This should mask the -lc++ problem in the gildas build system, except that (per #59753) the portfile isn't passing the necessary -stdlib=... flag when building things with clang++, so it's still (erroneously now) building things for the compiler's default of libstdc++.

This problem would not occur on 10.9 or later, where Apple's default C++ stdlib is libc++, which explains why the user no longer sees the problem after upgrading the OS.