Root crashes when opening a saved TCanvas

Hi,

Try setting the break after the first failing run and, without exiting gdb, run a second time.

Cheers,
Philippe.

Hi Philippe,

Thanks (again!) for your help. I tried your suggestion where I ran root.exe in gdb, let it fail at opening a TCanvas, then set the breakpoint and ran it again without exiting gdb, but the results look pretty similar. (I’m attaching the output anyway.) This is getting weird – could I have somehow managed to compile/install root without its debug information maybe?
gdb_output2.txt (56.9 KB)

Hi,

code backtrace
#0 0x00007fff8ebc5588 in malloc_error_break ()
#1 0x00007fff8ebc6942 in free ()
(gdb) q[/code]Yes, this most likely indicates you have an optimized build. Rebuilding on debug will/should provide more information. It could also be that your gdb is ‘too old’ in which lldb should provide more information.

Cheers,
Philippe.

Aaaand down the rabbit hole I go. :slight_smile:

I installed a new copy of Root 5.34/34 in a different directory, with these options:

./configure --all --fail-on-missing --enable-mysql --enable-soversion --enable-rpath --enable-x11 --enable-xft --enable-gsl-shared --enable-roofit --with-clang --prefix=/Users/spiffyzha/Packages/root5_ --etcdir=/Users/spiffyzha/Packages/root5_/etc/root --libdir=/Users/spiffyzha/Packages/root5_/lib --incdir=/Users/spiffyzha/Packages/root5_/include --mandir=/Users/spiffyzha/Packages/root5_/share/man --build=debug

Sadly, this didn’t fix my issue with TCanvases though, as I was secretly hoping it might. And my copy of gdb does indeed appear to be too old, or at least it doesn’t offer me anything new. So LLDB it is, for the moment at least. Here’s what I’ve got:

[code]/Users/spiffyzha/Desktop/PreProcessor$ lldb /Users/spiffyzha/Packages/root5_/bin/root.exe
Current executable set to ‘/Users/spiffyzha/Packages/root5_/bin/root.exe’ (x86_64).
(lldb) breakpoint set -n malloc_error_break
Breakpoint 1: where = libsystem_c.dylib`malloc_error_break, address = 0x000000000002c584
(lldb) run -l
Process 92570 launched: ‘/Users/spiffyzha/Packages/root5_/bin/root.exe’ (x86_64)
1 location added to breakpoint 1
TFile * f = new TFile(“acanvas.root”);
TCanvas * t = f -> Get(“canvas1”);
root.exe(92570,0x7fff71031180) malloc: *** error for object 0x7fff71cfd570: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Process 92570 stopped

  • thread #1: tid = 0x2aaa4, 0x00007fff85726584 libsystem_c.dylibmalloc_error_break, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2 frame #0: 0x00007fff85726584 libsystem_c.dylibmalloc_error_break
    libsystem_c.dylib`malloc_error_break:
    -> 0x7fff85726584: pushq %rbp
    0x7fff85726585: movq %rsp, %rbp
    0x7fff85726588: nop
    0x7fff85726589: nopl (%rax)
    [/code]

So that’s more information at least, but I don’t know how to interpret it.

What is the stack trace at the point of failure?

Attach your ROOT file so that we can try it.
You write that you have two ROOT versions installed simultaneously.
How did you build them?
When building the second version, did you make sure that the libraries and executables belonging to the first version were not seen at all?
How do you switch between these two versions now?
Is is possible that one version sees libraries and/or executables which belong to the other one?
See also: Missing Canvas

The stack trace output and (one of) the root file(s) I’ve been using are both attached.

As far as my two builds of ROOT – I certainly tried to keep everything separated, but it was sort-of a process of trial and error, so it wouldn’t surprise me to learn that I overlooked something. I switch between them by calling the “thisroot.sh” script associated with the installation I want to use.

As for the specifics of the installations: I first installed ROOT v6.04.08 using gcc 5.1.0. In particular, I used these options:

cmake ../root-6.04.08_ -DCMAKE_INSTALL_PREFIX=/Users/spiffyzha/Packages/root6 -Dgminimal=ON -Droofit=ON -Dmysql=ON -Dcocoa=OFF -Dcxx11=ON -Dgsl-shared=OFF -DCMAKE_C_COMPILER=/usr/gcc-5.1.0/bin/gcc-5.1.0 -DCMAKE_CXX_COMPILER=/usr/gcc-5.1.0/bin/g++-5.1.0 -Dx11=ON -Dbuiltin-freetype=ON -Drpath=ON -Dsoversion=ON -Dfail-on-missing=ON -Dxft=ON -Dcling=ON

Basically, I need the ROOT libraries to link with things that use C++11, and I couldn’t make it work with a clang-based install of ROOT. The Root 6 interpreter actually seems to crash when I do pretty much anything, but I don’t care too much about that as long as I can link with its libraries.

Then, I went on to install Root 5 using clang, as described in my previous post (though previously without the “debug” option) – and this seems to work fine most of the time. This build is my default, I can link to its libraries with way less fuss than it takes for the GCC-based build, and the interpreter works nicely for most of the things.
acanvas.root (84.3 KB)
lldb_output.txt (10.2 KB)

That other thread has a lot of good information. I don’t know at this point whether or not I reset my environment variables prior to installing root 5 and root 6 previously, but I definitely didn’t do it when I reinstalled root 5 yesterday. I also found some ancient root files living in /opt/local/share and /opt/local/include . Based on their dates, they’re from an old install of root version 5.x (as well as from a simpler time when TCanvases still worked).

So, I’m going to try this: I’ll delete those files, delete both copies of root 5, get rid of anything pointing to a root installation within my environment variables (Do I need to worry about anything other than $ROOTSYS, $PATH, and $LD_LIBRARY_PATH??), and then reinstall root 5.

I had no problems on my Linux machine to open your file with ROOT 5.34/35 and 6.06/00.

Check “/usr/local/bin” (ROOT 5 produces up to about 29 executables and scripts), “/usr/local/lib”, “/usr/local/lib/root”, “/usr/local/etc/root”, “/etc/root” for any remnants of your old ROOT 5.
Looking at your “lldb_output.txt” file, “libRIO.so”, “libHist.so”, “libGpad.so” are without version numbers while another libraries are “*.5.so”, so it is possible that they come from different ROOT versions.

Check “CMAKE_PREFIX_PATH”, “DYLD_LIBRARY_PATH”, “LD_LIBRARY_PATH”, “LIBPATH”, “MANPATH”, “PATH”, “PYTHONPATH”, “ROOTSYS” (note: it seems that you actually want to “unset ROOTSYS” when building both versions), “SHLIB_PATH”.

(Also, always use “–enable-soversion” for ROOT 5 and “-Dsoversion=ON” for ROOT 6.)

BTW. I’m not sure if you are allowed to compile ROOT 6 with gcc on Mac OS X (I think it requires clang).

Hi,

In lldb in the failing case, what does the lldb command ‘image list’ prints?

Cheers,
Philippe.

Yeah, I think I’m not really supposed to. Alas, clang won’t do everything I need (or, more likely, I was insufficiently persuasive). It certainly took me long enough to get anything working with gcc, so I can see why folks would want to discontinue supporting this. :slight_smile:

So. I’ve left my semi-functional gcc-based installation of root 6 alone. It seems to at least be nicely contained within one particular directory. I removed all references to anything that looked ROOT-like from all of those environment variables, and I trashed all the ROOT files I found outside the ROOT 6 install directory. And then I re-built and reinstalled ROOT 5, as before, with these options:

./configure --all --fail-on-missing --enable-mysql --enable-soversion --enable-rpath --enable-x11 --enable-xft --enable-gsl-shared --enable-roofit --with-clang --prefix=/Users/spiffyzha/Packages/root5_ --etcdir=/Users/spiffyzha/Packages/root5_/etc/root --libdir=/Users/spiffyzha/Packages/root5_/lib --incdir=/Users/spiffyzha/Packages/root5_/include --mandir=/Users/spiffyzha/Packages/root5_/share/man --build=debug

When it was done installing, I called its “thisroot.sh” script and loaded up ROOT. It still won’t open a TCanvas for me though.

I’ve attached lldb output from my shiny new installation, complete with a ‘thread backtrace’ and ‘image list’.

It’s interesting what you noticed about the versions on some of my libraries. It looks like ‘libRIO.so’, ‘libHist.so’, and ‘libGpad.so’ are indeed associated with Root 6. (At least … I think?? Root 5 and Root 6 install locations both contain a file called “libRIO.so” (and etc), but for the Root 6 install it’s a “real” library file, where as for Root 5 it’s just an alias to “libRIO.5.34.so” – but the trace would probably find the original and not just the symbolic link that got called, right?)

But … the Root5 copies of “libRIO.5.34.so” and “libRIO.so” both live in the Root5 ‘libdir’ as specified above during the installation, so I don’t know why Root5 would try to look elsewhere. In fact, there’s nothing involving Root6 in any of the environment variables I checked:

[code] which root /Users/spiffyzha/Packages/root5_/bin/root echo ROOTSYS /Users/spiffyzha/Packages/root5_ echo PATH /opt/X11/include:/opt/X11/bin:/Users/spiffyzha/Packages/roody/bin:/usr/local/mysql/bin:/usr/local/mysql/include:/usr/gcc-5.1.0/bin:/Users/spiffyzha/geant4_workdir/bin/Darwin-g++:/Users/spiffyzha/Packages/geant4_v964_gcc/install/bin:/opt/local/bin:/opt/local/sbin:/Library/Frameworks/Python.framework/Versions/2.7/bin:/Users/spiffyzha/Packages/root5_/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin echo LD_LIBRARY_PATH /Users/spiffyzha/Packages/root5_/lib echo $CMAKE_PREFIX_PATH

$ echo DYLD_LIBRARY_PATH /Users/spiffyzha/Packages/MiscLibs:/usr/local/mysql/bin:/usr/local/mysql/include:/usr/local/mysql/lib:/Users/spiffyzha/Packages/roody/bin:/usr/local/mysql/bin:/usr/local/mysql/include:/usr/gcc-5.1.0/bin:/Users/spiffyzha/geant4_workdir/bin/Darwin-g++:/Users/spiffyzha/Packages/geant4_v964_gcc/install/bin:/opt/local/bin:/opt/local/sbin:/Library/Frameworks/Python.framework/Versions/2.7/bin:/Users/spiffyzha/Packages/root5_/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/Users/spiffyzha/Packages/geant4_v964_gcc/install/lib:/Users/spiffyzha/Packages/geant4_v964_gcc/install/lib:/Users/spiffyzha/Packages/root5_/lib echo LIBPATH /Users/spiffyzha/Packages/root5_/lib echo MANPATH /Users/spiffyzha/Packages/root5_/share:/usr/share/man:/usr/local/share/man:/opt/X11/share/man echo PYTHONPATH /Users/spiffyzha/Packages/root5_/lib echo $SHLIB_PATH
/Users/spiffyzha/Packages/root5_/lib[/code]
lldb_output2.txt (31.1 KB)

Hi,

The problem is most likely:[ 6] EAA2B53E-EADE-39CF-A0EF-FB9D4940672A 0x00007fff8c3f7000 /usr/lib/libstdc++.6.dylib [ 7] DA8891C5-4FB7-3F5E-9596-B9A7B95EC1E6 0x0000000101795000 /usr/local/lib/liblzma.5.dylib [ 8] 773F4826-AAE4-3DF6-AAF2-F24A8E3DFBC6 0x00000001017b8000 /opt/local/lib/libpcre.1.dylib [ 9] DD7AADDF-3D00-34D6-846D-05C18EE67ABD 0x0000000101819000 /usr/local/lib/libstdc++.6.dylib

where we can see that two different libstdc++ are being used, one from /usr/lib and one for /usr/local/lib. They are likely different and incompatible leading to a crash in std::string: * frame #0: 0x00007fff85726584 libsystem_c.dylib`malloc_error_break frame #1: 0x00007fff85727942 libsystem_c.dylib`free + 321 frame #2: 0x0000000101885518 libstdc++.6.dylib`std::string::_M_mutate(unsigned long, unsigned long, unsigned long) + 392 frame #3: 0x000000010188598e libstdc++.6.dylib`std::string::_M_replace_safe(unsigned long, unsigned long, char const*, unsigned long) + 30.

To solve the problem, the best solution is likely to ask configure and/or cmake to use the builtin version of lzma and pcre.

Cheers,
Philippe.

I gave this a try, but I still had the same problem.

For completeness, here’s what I did: I cleaned out the environment variables, tossed my previous root5 install, and ran this for the configure script:

./configure --all --fail-on-missing --enable-mysql --enable-soversion --enable-rpath --enable-x11 --enable-xft --enable-gsl-shared --enable-roofit --with-clang --prefix=/Users/spiffyzha/Packages/root5 --etcdir=/Users/spiffyzha/Packages/root5/etc/root --libdir=/Users/spiffyzha/Packages/root5/lib --incdir=/Users/spiffyzha/Packages/root5/include --mandir=/Users/spiffyzha/Packages/root5/share/man --build=debug --enable-builtin-lzma --enable-builtin-pcre

…and the configure script came back with this:

Enabled support for asimage, astiff, bonjour, builtin_afterimage, builtin_ftgl, builtin_freetype, builtin_glew, builtin_pcre, builtin_lzma, cintex, cocoa, explicitlink, fink, fftw3, gviz, gdml, genvector, gsl_shared, http, krb5, ldap, mathmore, memstat, minuit2, mysql, odbc, opengl, pgsql, python, reflex, roofit, ruby, rpath, shared, soversion, sqlite, ssl, table, tmva, unuran, vc, vdt, xml.

So I built and installed it, and ran its thisroot.sh script. Then I tried to load up a TCanvas from within the root interpreter. No luck. (See lldb_output3.txt, which is attached.)

I noticed that fink was enabled (and therefore would have been this whole time), which can’t possibly be a good idea given the nature of the problem. So I disabled it and tried again:

./configure --all --fail-on-missing --enable-mysql --enable-soversion --enable-rpath --enable-x11 --enable-xft --enable-gsl-shared --enable-roofit --with-clang --prefix=/Users/spiffyzha/Packages/root5 --etcdir=/Users/spiffyzha/Packages/root5/etc/root --libdir=/Users/spiffyzha/Packages/root5/lib --incdir=/Users/spiffyzha/Packages/root5/include --mandir=/Users/spiffyzha/Packages/root5/share/man --build=debug --enable-builtin-lzma --enable-builtin-pcre --disable-fink
Enabled support for asimage, astiff, bonjour, builtin_afterimage, builtin_ftgl, builtin_freetype, builtin_glew, builtin_pcre, builtin_lzma, cintex, cocoa, explicitlink, gdml, genvector, gsl_shared, http, krb5, ldap, mathmore, memstat, minuit2, mysql, odbc, opengl, pgsql, python, reflex, roofit, ruby, rpath, shared, soversion, sqlite, ssl, table, tmva, unuran, vc, vdt, xml.

Same problem though. See lldb_output4.txt (which looks the same as lldb_output3.txt, to my untrained eye). But in particular, I notice that this is still there:

[ 6] EAA2B53E-EADE-39CF-A0EF-FB9D4940672A 0x00007fff8c3f7000 /usr/lib/libstdc++.6.dylib [ 7] DD7AADDF-3D00-34D6-846D-05C18EE67ABD 0x00000001017c4000 /usr/local/lib/libstdc++.6.dylib
lldb_output4.txt (30.9 KB)
lldb_output3.txt (30.9 KB)

Then we need to track down where it comes from …

Can you run ‘otool -L’ on each of the main ROOT libraries (libCore.so, libRIO.so, libCling.so, libRint.so, libThread.so and also on libMatrix.so, libHist.so, libGraf.so, libGpad.so, libGQuartz.so,libGui.so, libGCocoa.so

Cheers,
Philippe

Neat, I didn’t know you could do that! :slight_smile:

Output is attached.

It looks like libCore.so is the only one that uses “/usr/local/lib/libstdc++.6.dylib”, and all the others use “/usr/lib/libstdc++.6.dylib”. …with the exception of libCling.so. Does that one definitely come with ROOT 5 ? Because the only copy I have of that is associated with my ROOT 6 install.
otool_output.txt (11.7 KB)

libCling … Does that one definitely come with ROOT 5 ?

No :slight_smile:. In v5, the equivalent in libCint.so.

Cheers,
Philippe.

So, we now need to understand why libCore.5.so is linked against /usr/local/lib/libstdc++.6.dylib.

What is the link line for libCore v5? (To see just rm libCore*so from the build directory and re-run make).

Cheers,
Philippe.

Hah! Okay. :slight_smile: Well, there are no surprises with libCint.so either, so that’s good:

/Users/spiffyzha/Packages/root5/lib$ otool -L libCint.so libCint.so: /Users/spiffyzha/Packages/root5/lib/libCint.5.so (compatibility version 5.0.0, current version 5.34.34) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)

At any rate, here’s the output when I delete libCore*.so from the build directory and run make again:

[code]/Users/spiffyzha/Desktop/root$ make
clang++ -dynamiclib -single_module -Wl,-dead_strip_dylibs -install_name /Users/spiffyzha/Packages/root5/lib/libCore.5.so -g -m64 -mmacosx-version-min=10.8 -o lib/libCore.5.34.so core/base/src/InitGui.o core/base/src/ManualBase4.o core/base/src/Match.o core/base/src/String.o core/base/src/Stringio.o core/base/src/TApplication.o core/base/src/TApplicationImp.o core/base/src/TAtt3D.o core/base/src/TAttAxis.o core/base/src/TAttBBox.o core/base/src/TAttBBox2D.o core/base/src/TAttFill.o core/base/src/TAttLine.o core/base/src/TAttMarker.o core/base/src/TAttPad.o core/base/src/TAttText.o core/base/src/TBase64.o core/base/src/TBenchmark.o core/base/src/TBrowser.o core/base/src/TBrowserImp.o core/base/src/TBuffer.o core/base/src/TBuffer3D.o core/base/src/TCanvasImp.o core/base/src/TColor.o core/base/src/TColorGradient.o core/base/src/TContextMenu.o core/base/src/TContextMenuImp.o core/base/src/TControlBarImp.o core/base/src/TDatime.o core/base/src/TDirectory.o core/base/src/TEnv.o core/base/src/TError.o core/base/src/TException.o core/base/src/TExec.o core/base/src/TFileCollection.o core/base/src/TFileInfo.o core/base/src/TFolder.o core/base/src/TGuiFactory.o core/base/src/TInetAddress.o core/base/src/TInspectorImp.o core/base/src/TMD5.o core/base/src/TMacro.o core/base/src/TMathBase.o core/base/src/TMemberInspector.o core/base/src/TMessageHandler.o core/base/src/TNamed.o core/base/src/TObjString.o core/base/src/TObject.o core/base/src/TObjectSpy.o core/base/src/TPRegexp.o core/base/src/TParameter.o core/base/src/TPluginManager.o core/base/src/TProcessID.o core/base/src/TProcessUUID.o core/base/src/TQCommand.o core/base/src/TQConnection.o core/base/src/TQObject.o core/base/src/TROOT.o core/base/src/TRef.o core/base/src/TRefCnt.o core/base/src/TRegexp.o core/base/src/TRemoteObject.o core/base/src/TStopwatch.o core/base/src/TStorage.o core/base/src/TString.o core/base/src/TStringLong.o core/base/src/TStyle.o core/base/src/TSysEvtHandler.o core/base/src/TSystem.o core/base/src/TSystemDirectory.o core/base/src/TSystemFile.o core/base/src/TTask.o core/base/src/TTime.o core/base/src/TTimeStamp.o core/base/src/TTimer.o core/base/src/TUUID.o core/base/src/TUri.o core/base/src/TUrl.o core/base/src/TVirtualFFT.o core/base/src/TVirtualGL.o core/base/src/TVirtualMonitoring.o core/base/src/TVirtualMutex.o core/base/src/TVirtualPS.o core/base/src/TVirtualPad.o core/base/src/TVirtualPadEditor.o core/base/src/TVirtualPadPainter.o core/base/src/TVirtualPerfStats.o core/base/src/TVirtualViewer3D.o core/base/src/TVirtualX.o core/cont/src/TArray.o core/cont/src/TArrayC.o core/cont/src/TArrayD.o core/cont/src/TArrayF.o core/cont/src/TArrayI.o core/cont/src/TArrayL.o core/cont/src/TArrayL64.o core/cont/src/TArrayS.o core/cont/src/TBits.o core/cont/src/TBtree.o core/cont/src/TClassTable.o core/cont/src/TClonesArray.o core/cont/src/TCollection.o core/cont/src/TExMap.o core/cont/src/THashList.o core/cont/src/THashTable.o core/cont/src/TIterator.o core/cont/src/TList.o core/cont/src/TMap.o core/cont/src/TObjArray.o core/cont/src/TObjectTable.o core/cont/src/TOrdCollection.o core/cont/src/TRefArray.o core/cont/src/TRefTable.o core/cont/src/TSeqCollection.o core/cont/src/TSortedList.o core/meta/src/TBaseClass.o core/meta/src/TCint.o core/meta/src/TClass.o core/meta/src/TClassGenerator.o core/meta/src/TClassMenuItem.o core/meta/src/TClassRef.o core/meta/src/TDataMember.o core/meta/src/TDataType.o core/meta/src/TDictAttributeMap.o core/meta/src/TDictionary.o core/meta/src/TFunction.o core/meta/src/TGenericClassInfo.o core/meta/src/TGlobal.o core/meta/src/TInterpreter.o core/meta/src/TIsAProxy.o core/meta/src/TMethod.o core/meta/src/TMethodArg.o core/meta/src/TMethodCall.o core/meta/src/TRealData.o core/meta/src/TSchemaRule.o core/meta/src/TSchemaRuleSet.o core/meta/src/TStreamerElement.o core/meta/src/TToggle.o core/meta/src/TToggleGroup.o core/meta/src/TVirtualStreamerInfo.o core/unix/src/TUnixSystem.o core/macosx/src/CocoaUtils.o core/macosx/src/TMacOSXSystem.o core/zip/src/ZDeflate.o core/zip/src/ZInflate.o core/zip/src/RZip.o core/zip/src/Compression.o core/lzma/src/ZipLZMA.o core/clib/src/Demangle.o core/clib/src/attach.o core/clib/src/detach.o core/clib/src/getpagesize.o core/clib/src/keys.o core/clib/src/mcalloc.o core/clib/src/mfree.o core/clib/src/mmalloc.o core/clib/src/mmapsup.o core/clib/src/mmcheck.o core/clib/src/mmemalign.o core/clib/src/mmstats.o core/clib/src/mmtrace.o core/clib/src/mrealloc.o core/clib/src/mvalloc.o core/clib/src/sbrksup.o core/clib/src/snprintf.o core/clib/src/strlcat.o core/clib/src/strlcpy.o core/metautils/src/RConversionRuleParser.o core/metautils/src/TClassEdit.o core/textinput/src/Getline.o core/textinput/src/Getline_color.o core/textinput/src/textinput/Editor.o core/textinput/src/textinput/History.o core/textinput/src/textinput/KeyBinding.o core/textinput/src/textinput/Range.o core/textinput/src/textinput/SignalHandler.o core/textinput/src/textinput/StreamReader.o core/textinput/src/textinput/StreamReaderUnix.o core/textinput/src/textinput/StreamReaderWin.o core/textinput/src/textinput/TerminalConfigUnix.o core/textinput/src/textinput/TerminalDisplay.o core/textinput/src/textinput/TerminalDisplayUnix.o core/textinput/src/textinput/TerminalDisplayWin.o core/textinput/src/textinput/TextInput.o core/textinput/src/textinput/TextInputContext.o core/base/src/G__Base1.o core/base/src/G__Base2.o core/base/src/G__Base3.o core/cont/src/G__Cont.o core/meta/src/G__Meta.o core/unix/src/G__Unix.o core/macosx/src/G__Macosx.o core/zip/src/G__Zip.o core/clib/src/G__Clib.o core/metautils/src/G__MetaUtils.o core/textinput/src/G__TextInput.o -ldl -Llib -lCint -framework Cocoa -L/usr/local/lib -lz lib/liblzma.a -lpthread lib/libpcre.a -compatibility_version 5 -current_version 5.34.34
ln -fs libCore.5.34.so lib/libCore.so
==> lib/libCore.5.34.so done
bin/rlibmap -o lib/libCore.rootmap -l lib/libCore.so -d -c /Users/spiffyzha/Desktop/root/core/base/inc/LinkDef1.h /Users/spiffyzha/Desktop/root/core/base/inc/LinkDef2.h /Users/spiffyzha/Desktop/root/core/base/inc/LinkDef3.h /Users/spiffyzha/Desktop/root/core/cont/inc/LinkDef.h /Users/spiffyzha/Desktop/root/core/meta/inc/LinkDef.h /Users/spiffyzha/Desktop/root/core/zip/inc/LinkDef.h /Users/spiffyzha/Desktop/root/core/unix/inc/LinkDef.h /Users/spiffyzha/Desktop/root/core/macosx/inc/LinkDef.h /Users/spiffyzha/Desktop/root/core/clib/inc/LinkDef.h /Users/spiffyzha/Desktop/root/core/metautils/inc/LinkDef.h /Users/spiffyzha/Desktop/root/core/textinput/inc/LinkDef.h

============================================================
=== ROOT BUILD SUCCESSFUL. ===
=== Run ‘make install’ now. ===

/Users/spiffyzha/Desktop/root$
[/code]

So I see that this does indeed link with /usr/local/lib, but beyond that I’m not really sure what this tells us.

Hi,

I see -L/usr/local/lib -lz and I assume it does find a libz.so in /usr/local/lib which is likely not the one we want. To work-around the problem, try using the built-in zip library: --enable-builtin-zlib

Cheers,
Philippe.

Well, try to configure your ROOT using “–enable-builtin-zlib”.

Do you know where does the /usr/local/lib/libstdc++.* come from?
Try “locate libstdc++” … according to your “otool_output.txt” file, you seem to have at least three different versions installed.