Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#43825 closed defect (invalid)

root5: Undefined symbols for architecture x86_64

Reported by: peter.skands@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: mattiafrancescomoro@…, cjones051073 (Chris Jones), mojca (Mojca Miklavec)
Port: root5

Description (last modified by neverpanic (Clemens Lang))

I'm using macports with the newest root port and gcc 4.8:

root5 @5.34.18_0+cocoa+gcc48+graphviz+gsl+minuit2+opengl+roofit+soversion+ssl+tmva+xml

"port install root5" works fine, and so does most running and linking of the included executables/libraries. But when linking the ROOT libraries to compile an executable that manipulates ROOT graphs, I get the following specific errors:

Undefined symbols for architecture x86_64:
  "TAttMarker::SaveMarkerAttributes(std::basic_ostream<char, std::char_traits<char> >&, char const*, int, int, int)"
  "TGraphAsymmErrors::SavePrimitive(std::basic_ostream<char, std::char_traits<char> >&, char const*)"
  "TAttFill::SaveFillAttributes(std::basic_ostream<char, std::char_traits<char> >&, char const*, int, int)"
  "TAttLine::SaveLineAttributes(std::basic_ostream<char, std::char_traits<char> >&, char const*, int, int, int)"
 ld: symbol(s) not found for architecture x86_64

Note: the ROOT libraries I am linking are the following:

-L/opt/local/lib/root5 -lCore -lCint -lGpad -lGraf -lHist -lMathCore -lMatrix -lRIO -lThread

I've been having this problem ever since I upgraded to OSX Mavericks, some months ago, and am posting it here since it looks like the 64-bit libraries installed by this port may be missing a few compiled functions defined in the headers. So far I haven't found any discussion of this particular issue elsewhere. My apologies if this is simply due to some stupidity on my part or an intrinsic ROOT problem, not specific to macports. Note that the code I compile successfully links a lot of other ROOT functionality; it is just these 4 functions that fail at link time.

Change History (10)

comment:1 Changed 10 years ago by neverpanic (Clemens Lang)

Cc: mattiafrancescomoro@… jonesc@… added
Description: modified (diff)

I think this is a C++ runtime library problem. Which compiler do you use to link your program? Which standard library is used? Which standard library is used by the root libs?

Please remember to preview your post and use WikiFormatting when posting in trac. Also make sure to Cc the maintainer, if any.

comment:2 Changed 10 years ago by cjones051073 (Chris Jones)

I concur, this looks like a C++ runtime issue.

Note that the +gcc48 variant does *not* enable the use of gcc to build the C++ sources. It is only used to pick the gfortran version used to build the small fraction of F77 code still in ROOT (legacy HBOOK stuff). You should use the same C++ compiler for your private code as used to build ROOT, which for the most recent OSX releases will be clang.

You can check this using

MacBookPro ~ > root-config5 --cxx
/usr/bin/clang++
MacBookPro ~ > root-config5 --cc
/usr/bin/clang

Building with g++ from GCC is specifically *not* supported (and removed as an option several versions back) as it just leads to issues with mixing C++ runtimes.

Chris

Last edited 10 years ago by cjones051073 (Chris Jones) (previous) (diff)

comment:3 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Keywords: x86_64 removed
Summary: Undefined symbols for architecture x86_64root5: Undefined symbols for architecture x86_64

comment:4 Changed 10 years ago by peter.skands@…

Thanks guys. I was indeed using gcc4.8 as the main compiler and linker. Some additional fortran code needed to be linked which previously had not worked with clang (needed the GNU -lgfortran flag). I now revised the fortran parts to not need the GNU fortran library and am able to compile and link the full code with clang++ (using gcc4.8 for the fortran parts), with the root5 libraries from macports linked in successfully as well. Thanks for the input on how to resolve it; it had not been clear to me that the +gcc48 only referred to some legacy fortran HBOOK code libraries. That said, however, since my code is intended for public release, I am still a bit worried that it is effectively not possible to use this port with gcc any more, but I think at least I now know how to inform my users to resolve any issues that might give rise to.

comment:5 Changed 10 years ago by mojca (Mojca Miklavec)

Cc: mojca@… added

Cc Me!

comment:6 Changed 10 years ago by mojca (Mojca Miklavec)

I still think that you might be able to use gcc4.8 if you install root5 explicitly with gcc:

port install root5 configure.compiler=macports-gcc-4.8

and then install your software with the same compiler.

If you want to do a favour to your users who install ROOT via MacPorts I would suggest you to make a port for your package as well.

There are still many users out there who either install ROOT from source (or take the binaries from upstream). I suspect that if they use the same compiler as for compiling ROOT, that should work, so it's not that gcc would be a-priori impossible to use. But you can also ask ROOT developers for advice. Most users would simply take the default compiler, I guess.

I agree that users would probably understood the variant name gfortran48 better than gcc48. `gccXY' might be confused for using gcc also as the C(++) compiler.

Can this ticket be closed or is there anything else to be solved?

comment:7 Changed 10 years ago by peter.skands@…

Thanks mojca, I will definitely add some advice in my installation troubleshooting section for macports users along the lines of what you say, and consider making a port too. As far as I'm concerned the ticket can be closed. Do I do it, or one of you?

comment:8 Changed 10 years ago by mojca (Mojca Miklavec)

Resolution: invalid
Status: newclosed
Version: 2.3.0

comment:9 in reply to:  6 Changed 10 years ago by cjones051073 (Chris Jones)

Replying to mojca@…:

I still think that you might be able to use gcc4.8 if you install root5 explicitly with gcc:

port install root5 configure.compiler=macports-gcc-4.8

and then install your software with the same compiler.

Note, if you try and do this, then you will have to make sure *all* the other Ports than provide libraries using a C++ runtime (and ports they use etc. etc.) are also built using gcc 4.8, which is not the case by default. Effectively you will have to rebuild your entire MacPorts stack using gcc as the default compiler. The reason for this is you absolutely cannot mix the libc++ runtime (as used by clang) with the MacPorts libstdc++ runtime (as used by gcc).

Apple have firmly placed their cap on Clang. They will not touch anything GPL3 (which gcc is). If you really want to support users on OSX10.9 or newer, then in practise clang ios the only sane way to go, IMHO. Trying to stick with gcc is only going to get harder and harder...

So whilst the above might be possible, I really do not recommend it, nor is it supported.

Chris

comment:10 in reply to:  6 Changed 10 years ago by cjones051073 (Chris Jones)

I agree that users would probably understood the variant name gfortran48 better than gcc48. `gccXY' might be confused for using gcc also as the C(++) compiler.

The root port simply follow the convention as outlined in

https://trac.macports.org/wiki/PortfileRecipes#fortran

for setting up fortran compilers.

Also, the port info on the variants is I think quite clear, so I don't really think there is much need to change this now. The gcc48 variant is anyway enabled by default, and I doubt most users have a real reason to switch to using a different gcc for gfortran.

Chris

Last edited 10 years ago by cjones051073 (Chris Jones) (previous) (diff)
Note: See TracTickets for help on using tickets.