EL Capitan (osx 10.11) issue

[Li Fan]

Dear all,

I have a issue after I upgraded to OSX 10.11 (EL Capitan).

When I type cmake . then make run it displayed the following message:

     dyld: Library not loaded: libmesquite.11.dylib

I am using the dealii-8.1.0-mac_bundle-parallel-osx10.9-clang5.1.mpkg and modified the version of clang to 7.0.0.

but If I type cmake .  then make then ./executablefile  it works. It seems just the make run didn't work.

Any suggestion?

thanks,

Li

[Matthias Maier]

On Mon, Oct 5, 2015, at 11:52 CDT, Li Fan <fanl...@gmail.com> wrote:

> dyld: Library not loaded: libmesquite.11.dylib

I have seen this very same issue on a Mac of a grad student here on
Friday last week.

The behavior of the dynamic loader seems to have changed - it does not
pick up our hints for library locations any more.

@Luca: Do you have an idea how to mitigate this? (Do we need to populate
another environment variable instead of PATH - or can we fix this with
some RPATH annotation?)

[Luca Heltai]

I think it should be possible to fix this with some RPATH annotation, but I have to experiment with it a little bit.

Can you uninstall that package and use the new one (the one that comes with the app instead of the pkg?). 8.1.0 is a little old for your system, and I think the new one should still work on your system (https://github.com/dealii/dealii/releases/download/v8.3.0/deal.II-8.3.0.nocxx14.dmg)

Next week I’ll try to come up with a solution on a newly installed ElCapitain…

Best,
Luca.

--
Luca Heltai <luca....@gmail.com>
http://people.sissa.it/~heltai/
Scuola Internazionale Superiore di Studi Avanzati
Phone: +39 040 3787 449, Office: 622
--
There are no answers, only cross references

> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dealii+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Li Fan]

Thanks. I will try the 8.3 version.

You received this message because you are subscribed to a topic in the Google Groups "deal.II User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dealii/NsniOXPvOyo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dealii+un...@googlegroups.com.

[Lei Qiao]

Thanks. I will try the 8.3 version.

I tried the git develop version and the same issue exists.  

[luca.heltai]

It is working fine for me…

Can you try installing the old cmake? 2.8.12 works on my system.

I’m just creating a new package with the latest master version. As soon as it’s ready I’ll post a link to the binary.

L.

> On 22 Oct 2015, at 5:27, Lei Qiao <qiao...@gmail.com> wrote:
>
> Thanks. I will try the 8.3 version.
>
> I tried the git develop version and the same issue exists.
>

[luca.heltai]

Here is a link to my latest build, which works fine on my mac (with cmake 2.8.12, though…).

https://github.com/luca-heltai/dealii/releases/tag/v8.4.pre.3

Can you see if this gives you the same issues?

Best,

Luca.

> On 22 Oct 2015, at 5:27, Lei Qiao <qiao...@gmail.com> wrote:
>

> Thanks. I will try the 8.3 version.
>
> I tried the git develop version and the same issue exists.
>

[Li Fan]

Hi Luca, thanks. I will try it.

[Lei Qiao]

On Thursday, October 22, 2015 at 4:15:29 AM UTC-5, Luca Heltai wrote:

It is working fine for me…

Can you try installing the old cmake? 2.8.12 works on my system.

I switched back to cmake  2.8.12.2 with homebrew but it doesn't save me.

Could you tell me it is in which cmake script that we provide hints for library locations to the dynamic loader?

The Trilinos path that I provided to deal.II cmake file is a symbolic link, I am not sure whether this will cause problem.

[luca.heltai]

Did you add to your .profile or .bashrc the following lines?

export DEAL_II_CONF_SILENT=ON
. /Applications/deal.II.app/Contents/Resources/share/deal.II/dealii.conf

This exports DYLD_LIBRARY_PATH to the correct path. We don’t use cmake scripts to hint for these. My DYLD looks like this:

503-heltai: ~[master] $ export | grep DYLD_LIBRARY
declare -x DYLD_LIBRARY_PATH="/Applications/deal.II.app/Contents/Resources/opt/trilinos-ba77c1f/lib:/Applications/deal.II.app/Contents/Resources/opt/sundials-2.6.1/lib:/Applications/deal.II.app/Contents/Resources/opt/slepc-d8e80ab/lib:/Applications/deal.II.app/Contents/Resources/opt/petsc-9fbf19a/lib:/Applications/deal.II.app/Contents/Resources/opt/p4est-fb278b3/lib:/Applications/deal.II.app/Contents/Resources/opt/openmpi-1.6.5/lib:/Applications/deal.II.app/Contents/Resources/opt/oce-f6d3095/lib:/Applications/deal.II.app/Contents/Resources/opt/gfortran-5.0/lib:/Applications/deal.II.app/Contents/Resources/opt/deal2lkit-dev/lib:/Applications/deal.II.app/Contents/Resources/opt/boost-1.58.0/lib:/Applications/deal.II.app/Contents/Resources/opt/assimp-dev/lib:/Applications/deal.II.app/Contents/Resources/opt/arpack-ng/lib:/Applications/deal.II.app/Contents/Resources/lib::/usr/local/Dakota/lib”

Yours should look very similar. If this is there, then you should have

/Applications/deal.II.app/Contents/Resources/opt/trilinos-ba77c1f/lib

in your DYLD_PATH, and deal.II should find those libraries just fine…

L.

[Lei Qiao]

My system DYLD_LIBRARY_PATH is correct, but the make script does't inherit it.

Here is an explanation to how does El Captain treat the variable DYLD_LIBRARY_PATH: https://github.com/oracle/node-oracledb/issues/231

To confirm this, I hacked the CMake generated make file with

echo "*******"
echo `pwd`
echo DYLD_LIBRARY_PATH = "${DYLD_LIBRARY_PATH}"
echo LD_LIBRARY_PATH = ${LD_LIBRARY_PATH}
echo PATH = ${PATH}
echo USER = ${USER}
echo "*******"

and got the output

*******

/Users/qiaol/devel/dealii/examples/step-33

DYLD_LIBRARY_PATH = 

LD_LIBRARY_PATH =

PATH = /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/TeX/texbin:/Users/qiaol/.bin:/Applications/Gmsh.app/Contents/MacOS:/Users/qiaol/Library/astyle:/Users/qiaol/Library/openmpi/bin:/Users/qiaol/Library/cgnslib/bin

USER = qiaol

*******

 

It seem that Apple learned how to trouble users from SELinux...

Have you turned off the System Integrity Protection (SIP) before?

[Lei Qiao]

After turned off SIP, "make run" works as usual :-)

Here is a tutorial on how to change SIP status.

http://www.macworld.com/article/2986118/security/how-to-modify-system-integrity-protection-in-el-capitan.html

[luca.heltai]

I never turned off SIP before, though.

:(

L.

[Lei Qiao]

On Sunday, October 25, 2015 at 11:38:35 AM UTC-5, Luca Heltai wrote:

I never turned off SIP before, though.

That's weird. 

Are you still using the system default shell and make?

[luca.heltai]

Yes.

I’m using the default, and this is the output of my

csrutil status:
System Integrity Protection status: enabled.


I’d suggest NOT to turn SIP off…

I’m looking for a definitive solution, which should be to run a scripts that sets correctly all library paths before distributing the package, adding manually @rpath to each library, and then reconfiguring deal.II to use @rpath…

L.

[Jean-Paul Pelteret]

Hi Luca and Lei,

I spent the better half of this week fighting this issue for my project and associated example programs that live outside of the system path. I'm not certain that my and your scenarios coincide exactly, but perhaps my solution could be of use here. I used to use DYLD_FALLBACK_LIBRARY_PATH to specify the path to my project libraries but ran into what I think are similar problems to those that you've mentioned. For the record, SIP is active on my machine.

*** Most useful resources:

https://cmake.org/Wiki/CMake_RPATH_handling 

http://www.kitware.com/blog/home/post/510

To fix this, I found that I had to do the following:

1a. When building the library to which I link my executables, I had to add this (DEST_LIB is the installation directory):

if(APPLE)
    set(CMAKE_MACOSX_RPATH ON)
    set(CMAKE_SKIP_BUILD_RPATH FALSE)
    set(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
    set(CMAKE_INSTALL_RPATH "${DEST_LIB}")
    set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
    list(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES "${DEST_LIB}" isSystemDir)
    if("${isSystemDir}" STREQUAL "-1")
        set(CMAKE_INSTALL_RPATH "${DEST_LIB}")
    endif()
endif()

1b. Libraries were explicitly specified as shared (I'm not sure whether this is actually necessary)

ADD_LIBRARY(${TARGETLIB_FEM} SHARED
... <source files>...
)

2. When installing a build executable, I had to instruct CMake to set/reset the rpath once its copied to its final destination:

# Installation path
  INSTALL(
    TARGETS ${TARGET}
    DESTINATION ${CMAKE_SOURCE_DIR}/bin
  )

# Substitute @rpath for library path
if(APPLE)
  # if the install RPATH is not provided, the install ${TARGET} will have none
  SET_TARGET_PROPERTIES(${TARGET} PROPERTIES INSTALL_RPATH ${LIBFEM_MP_LIBRARY})
ENDIF()

The desired result is that when one runs

otool -l <file> | grep  LC_RPATH -A2

on both the originally built and installed executables, a non-null result is returned.

I hope that this may be of some use to you. 

J-P

[Lei Qiao]

I’d suggest NOT to turn SIP off…

I’m looking for a definitive solution, which should be to run a scripts that sets correctly all library paths before distributing the package, adding manually @rpath to each library, and then reconfiguring deal.II to use @rpath…

But every thing works fine for you with SIP,

 I think there must be an elegant solution that needs no change in deal.II or turning off SIP.

[luca.heltai]

We definitely need a change in deal.II. At the moment rpath support on OS X is broken in the building of the deal.II library, therefore all applications built with the CMake scripts included in the library are broken, because they rely on DYLD_LIBRARY_PATH being set.

For some obscure reasons which I could not pin down, on my system DYLD_LIBRARY_PATH is still used, and so I don’t need to turn off SIP. Turning off SIP is a really bad idea…

What is necessary is to configure or change all libraries in the package to use @rpath, and correctly instruct deal.II to build with @rpath on on mac os x.

This is the clean solution, which would also remove the necessity to use any type of script to launch deal.II, and would also allow one to move the library around, by simply renaming the app.

I’m working on it.

L

[Lei Qiao]

On Thursday, October 29, 2015 at 3:37:25 AM UTC-5, Luca Heltai wrote:

We definitely need a change in deal.II. At the moment rpath support on OS X is broken in the building of the deal.II library, therefore all applications built with the CMake scripts included in the library are broken, because they rely on DYLD_LIBRARY_PATH being set.

For some obscure reasons which I could not pin down, on my system DYLD_LIBRARY_PATH is still used, and so I don’t need to turn off SIP. Turning off SIP is a really bad idea…

What is necessary is to configure or change all libraries in the package to use @rpath, and correctly instruct deal.II to build with @rpath on on mac os x.

This is the clean solution, which would also remove the necessity to use any type of script to launch deal.II, and would also allow one to move the library around, by simply renaming the app.

I’m working on it.

That's great. Looking forward to your work. 

[Tristan Schlögl]

Hi there,

is there any news regarding the @rpath problem? I'm facing problems as well.

I'm working on a Mac with OSX 10.11.2 (El Capitan) and have the MacPorts gcc5 5.3.0_0 installed. I use deal.II together with Trilinos. I configured and compiled Trilinos 12.4.2 with the following commands

cmake \

  -D CMAKE_BUILD_TYPE=RELEASE \

  -D Trilinos_ENABLE_MOOCHO=ON \

  -D Trilinos_ENABLE_Sacado=ON \

  -D Trilinos_ENABLE_MueLu=ON \

  -D Trilinos_ENABLE_Stratimikos=ON \

  -D TPL_ENABLE_UMFPACK=ON \

  -D Trilinos_ENABLE_TESTS=ON \

  -D Trilinos_ENABLE_CXX11=ON \

  -D CMAKE_Fortran_COMPILER="/opt/local/bin/gfortran-mp-5" \

  -D CMAKE_CXX_COMPILER="/opt/local/bin/g++-mp-5" \

  -D CMAKE_C_COMPILER="/opt/local/bin/gcc-mp-5" \

  -D BUILD_SHARED_LIBS=ON \

  -D CMAKE_INSTALL_PREFIX="/Users/StTrSchl/libs/trilinos/lib/trilinos-12.4.2-release" \

  /Users/StTrSchl/libs/trilinos/src/trilinos-12.4.2-Source

and it compiled successfully. All Trilinos tests that are started by typing "ctest" run successful as well. I then compile deal.II 8.3.0 with the configuration options

-D CMAKE_INSTALL_PREFIX=/Users/StTrSchl/libs/deal_ii/lib/dealii-8.3.0

-D TRILINOS_DIR=/Users/StTrSchl/libs/trilinos/lib/trilinos-12.4.2-release

and deal.II configurates and compiles without any problems. However after deal.II make install, make test does abort, because it doesn't find some Trilinos libraries, even though I set the DYLD_LIBRARY variable to the Trilinos libraries path. I think that's because the new OSX El Capitan doesn't forward the DYLD_LIBRARY content to any child processes. To verify this, I went into the step-33 example folder (this example is using the Trilinos package Sacado) and run "cmake" and "make" which worked without any problems. When I now type make run, then the program aborts because it cannot find the Trilinos libraries. However, if I start the executable directly by typing "./step-33", then the programm runs and produces the expected output. I guess this is because I still have the DYLD_LIBRARY path set to Trilinos in the current terminal, however calling "make run" opens a child process that has DYLD_LIBRARY not set any more.

If I check the linked libraries of the step-33 executable by typing "otool -L step-33" then I can see that all libraries are given with a full absolute path, except the Trilinos libraries:

step-33:

/Users/StTrSchl/libs/deal_ii/lib/dealii-8.3.0/lib/libdeal_II.g.8.3.0.dylib (compatibility version 8.3.0, current version 8.3.0)

/opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.6)

/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)

libmoochothyra.12.dylib (compatibility version 12.0.0, current version 12.4.2)

libmoocho.12.dylib (compatibility version 12.0.0, current version 12.4.2)

librythmos.12.dylib (compatibility version 12.0.0, current version 12.4.2)

       ...

If I check what libraries are linked to the deal.II library, I can see the same problem:

libdeal_II.g.8.3.0.dylib:

/Users/StTrSchl/libs/deal_ii/lib/dealii-8.3.0/lib/libdeal_II.g.8.3.0.dylib (compatibility version 8.3.0, current version 8.3.0)

/opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.6)

/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)

libmoochothyra.12.dylib (compatibility version 12.0.0, current version 12.4.2)

libmoocho.12.dylib (compatibility version 12.0.0, current version 12.4.2)

librythmos.12.dylib (compatibility version 12.0.0, current version 12.4.2)

         ...

If I do the same check on the first linked Trilinos library, then I can as well see that all libraries are linked with an absolute path, except the Trilinos libraries theirselves:

libmoochothyra.12.dylib:

libmoochothyra.12.dylib (compatibility version 12.0.0, current version 12.4.2)

libmoocho.12.dylib (compatibility version 12.0.0, current version 12.4.2)

...

libteuchoscore.12.dylib (compatibility version 12.0.0, current version 12.4.2)

libkokkoscore.12.dylib (compatibility version 12.0.0, current version 12.4.2)

/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib (compatibility version 1.0.0, current version 1.0.0)

/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib (compatibility version 1.0.0, current version 1.0.0)

/opt/local/lib/libgcc/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.21.0)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

/opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

If I want to have my final executable step-33 such that all shared libraries are linked with their full absolute path, is this being done at the time of compilation of the Trilinos libraries, or when I compile the deal.II libraries, or can I just add some options when building my final executable step-33?

Tristan

[Luca Heltai]

The problem was solved long ago. If you look for follow-ups of the previous email, you'll find a link to an ipython script (it's in one of my public repositories on github, but I'm on my phone right now and cannot find it easily) which sets absolute paths for all libraries used by deal.II. This should solve your issue, and remove the need for DYLD_LIBRARY_PATH. 

Best,

Luca

[Tristan Schlögl]

That sounds good! Unfortunately, the only follow up I can find is the message of Lei Qiao saying "looking forward to your work". Can anyone again post the link to this ipython script?

Tristan

[Luca Heltai]

https://github.com/luca-heltai/d2-parallel-package

This is what I use to create binary packages. The script is included there. 

You can find a fairly recent working version of everything here:

https://github.com/luca-heltai/dealii

Under releases. 

Luca

--