Hi again, I did some progress on this topic, slowly as usual.
> On 16 Oct 2014, at 16:28, Brad King <brad.k...@kitware.com> wrote: > > On 10/13/2014 02:23 PM, Raffi Enficiaud wrote: >> I had a hard time making some stuff compile again with Matlab under Linux. >> The fact is that Matlab is shipped with its own version of libC, libhdf5, >> libboost etc, and sometimes the filenames are the same (eg. hdf5, or libc) >> but the subminor versions are not. If I understand properly, the fact that >> the filenames are the same prevents the dynamic loader of Linux to load the >> files that are referred by the mex file in their respective rpath (there >> is only one libhdf51.8.2.so in the matlab process). > > It's the SONAME that matters for the dynamic loader to find the libraries > at runtime. It is a string copied into the dependents and used by the > dynamic loader to find the matching file at runtime. Even with different SONAMES, the symbols may clash. I do not know exactly how it works, but the symbols brought by an SO are not in a specific namespace and might conflict with symbols from other SOs. If there is a proper way of saying that a particular shared library needs the symbols from a particular SO, and then uses these symbols only, then it should work. I tested with symbol mapping files but I could not get it to work. The latter solution is more portable at least. > >> Beside that, the >> symbols also may clash: I had an implementation with a dynamic loader under >> linux, but yet the boost symbols of my mex files were not loaded because >> same symbols were already there in the process. >> I found a technical solution to this on Linux: >> - the use of -Wl,--exclude-libs,ALL for the linker. > > According to "man ld" that option is only available on specific systems > (i386 PE). As you pointed out it is not available on OS X. > > I think the only reliable way to do this is to make sure your plugins > are built against the same libraries as Matlab, or to mangle the > symbols in your dependencies so they don't conflict with Matlab. This is not always possible: - Matlab does not ship the headers - Matlab has a lot of dependencies - I experienced problems even with the same version (example of HDF5 - same subminor - and libC - different subminor) > > This is outside the scope of what I think the FindMatlab module can > achieve, so it will have to be left to the application author. > For now please leave out the REDUCE_VISIBILITY option. I think > functionality like that, if provided by CMake, should be a more > general feature not specific to FindMatlab. Ok. What do you think about mimicking the mex compiler in terms of options set to the compiler? The -Wl,--exclude-libs,ALL is in fact set by the mex compiler for compiling the mex extensions under Linux. Then I will just drop the REDUCE_VISIBILITY from the interface and add some doc about the "best practices" that work better. > >> I am using this FindMatlab in two projects now, under OSX 10.9, >> Win7 Visual2013 and Ubuntu12.04. > > Great. In order to keep the module working, we will also need tests > for it. Please look at adding to the Tests/ directory a case for > using this module. The test case can be something we enable with > some explicit option. Then you can run a nightly build of CMake on > a machine of each platform with Matlab installed and enable the test. > Ideally you would have one for Windows, OS X, and Linux, at least. > Without regular testing the functionality is bound to regress as > changes are made to CMake. I added some tests: https://github.com/raffienficiaud/CMake/tree/matlab_wrapper/Tests/Module/Matlab2 But I have a quick question about the proper way of adding a test: https://github.com/raffienficiaud/CMake/blob/matlab_wrapper/Tests/CMakeLists.txt#L3095-L3099 So I am declaring tests in the CMakeLists.txt of the Matlab module test, and I am running ctest with the current configuration in order to run these tests. Is that the way of doing correctly this? If these tests should be ran in a nightly build process, should I add these tests only if Matlab is available? What are the best practices? For instance, this test https://github.com/raffienficiaud/CMake/blob/matlab_wrapper/Tests/Module/Matlab2/test_should_fail/CMakeLists.txt should fail because of a component lacking the the find_package option, and I test it with this: https://github.com/raffienficiaud/CMake/blob/matlab_wrapper/Tests/CMakeLists.txt#L3099 but I do not know if this is the right way to go. I also changed the set(MATLAB_ADDITIONAL_VERSIONS "release_name1" "corresponding_version1" "release_name2" "corresponding_version2" to set(MATLAB_ADDITIONAL_VERSIONS "release_name1=corresponding_version1" "release_name2=corresponding_version2" as you suggested in an earlier post. Best, Raffi > > Thanks, > -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
