mesa @7.8.2_2 installation => conflict with /System libGL.dylib

[karl.hauschild@…]

Hi all,

As mentioned in a previous (now closed) ticket ​https://trac.macports.org/ticket/26659 installation of geant4 resulted in conflicts between /opt/local/lib and /System/Librarry libraries. After many "uninstalls" I find the first problem arises when mesa is installed as a dependency of geant4.

The problem :

bash-3.2$ open errors.txt 
dyld: Symbol not found: _gll_noop
  Referenced from: /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
  Expected in: /opt/local/lib/libGL.dylib
 in /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
Trace/BPT trap

checking my system install :

bash-3.2$ otool -L /System//Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 
/System//Library/Frameworks/OpenGL.framework/Versions/A/OpenGL:
        /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
 .....        
        /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib (compatibility version 1.0.0, current version 1.0.0)
 ....
bash-3.2$

so this appears ok.

doing a

sudo port deactivate mesa

temporarily solves the problem of cohabitation, but is not a solution.

This seems to be an old problem : ​http://old.nabble.com/Symbol-not-found:-_gll_noop-td22241078.html.

How do I solve it ?

Cheers, Karl

[karl.hauschild@…]

I think the problem might have been that I had used

export   DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/opt/local/lib

INSTEAD OF

export   DYLD_FALLBACK_LIBRARY_PATH=$DYLD_FALLBACK_LIBRARY_PATH:/opt/local/lib

Perhaps this info should be put somewhere clearly ? In the FAQ section ?

Cheers, Karl

[jmroot (Joshua Root)]

Did one of our ports tell you to set a DYLD_* variable?

[karl.hauschild@…]

To be honest I can not remember why I put

DYLD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/local/lib

It might have been that some old instructions for macports installation stated that one should do this. Google pops up a few blogs that corroborate this. It
might just be that I did this from prior experience with other software installations.

However, if a DYLD_* is not set then this is what one gets when trying to run an example compiled using the geant4 package.

 [hauschild] : TestEm5 
dyld: Library not loaded: libiAIDA.dylib
  Referenced from: /Users/hauschild/geant4/bin/TestEm5
  Reason: image not found
Trace/BPT trap

This very same example worked with the previous version of geant4 that I had compiled myself from source and for which I had defined

#GEANT4.9.2
. /Users/hauschild/applications/geant4.9.2/src/geant4/env.sh
export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$APPS/CLHEP/lib

so this might be the source of my DYLD'ing......

​http://geant4.slac.stanford.edu/tutorial/installation/Geant4.9.3.p01/Mac/Geant4_9_3_p01_Mac_Installation.htm#_The_Geant4_Work

The upshot is : IF I want software compiled using the geant4 framework which has been
installed using macports to work along side system commands like "open" I must set

DYLD_FALLBACK_LIBRARY_PATH=$DYLD_FALLBACK_LIBRARY_PATH:/opt/local/lib

From a quick test with ROOT5.26 installed using macports it appears that I do not have to set any *LD*_LIBRARY_PATH
to compile and run my own codes.

So - is it really a problem with my configuration (as stated in an earlier ticket without helpful explanation) or is it a problem that
some packages do not have the library paths hard-coded.

Cheers, Karl

[jmroot (Joshua Root)]

Replying to karl.hauschild@…:

However, if a DYLD_* is not set then this is what one gets when trying to run an example compiled using the geant4 package.

 [hauschild] : TestEm5 
dyld: Library not loaded: libiAIDA.dylib
  Referenced from: /Users/hauschild/geant4/bin/TestEm5
  Reason: image not found
Trace/BPT trap

Yes, as I said before, the geant4 port has bugs; this is #23491. There's plenty of bad advice on the Internet unfortunately.

[jeremyhu (Jeremy Huddleston Sequoia)]

Setting DYLD_* in anything other than a testing / development environment is plain wrong. If we advise anything, anywhere, it should be to never set these unless you *REALLY* know what you're doing.

[karl.hauschild@…]

Replying to jeremyhu@…:

Setting DYLD_* in anything other than a testing / development environment is plain wrong. If we advise anything, anywhere, it should be to never set these unless you *REALLY* know what you're doing.

I have come to appreciate that after having these problems with the geant4 install and as you point out there is plenty of bad advice on the net.
Do you have an alternative to the DYLD_FALLBACK_LIBRARY_PATH method ?

Cheers.

[jeremyhu (Jeremy Huddleston Sequoia)]

install_name_tool -change <old> <new> <binary>

Check out the man page for that utility... but such a change should be put in the build system and not done by an end user.