[gdal-dev] osx compile failure

Ivan Lucena ivan.lucena at outlook.com
Wed Jan 16 07:57:22 PST 2019


Alan,

Did you used --without-libtool on ./configure?

If you do that, I believe that the file ./apps/gdalinfo and all other executables will be real executables and the makefiles will call "install_name_tool" to register the libgdal.dylib on the executables. In that case DYLD_LIBRARY_PATH will be ignored.

But, if you don't use --without-libtool on ./configure, that means you *do use libtool* and a lot of other interesting things will happen. Like, for example, the files that we think that are executables are not:

$ file apps/gdalinfo
apps/gdalinfo: POSIX shell script text executable, ASCII text
$ more apps/gdalinfo
#! /bin/sh

# gdalinfo - temporary wrapper script for .libs/gdalinfo
# Generated by libtool (GNU libtool) 2.4.6 Debian-2.4.6-0.1
#
# The gdalinfo program cannot be directly executed until all the libtool
# libraries that it depends on are installed.
#
# This wrapper script should never be moved out of the build directory.
# If it is, it will not operate correctly.

# Sed substitution that helps us do robust quoting.  It backslashifies
# metacharacters that are still active within double-quoted strings.
...

This is just the initial comments (whatever they means by "libtool libraries are installed") and there is a lot of lines trying to set and reset DYLD_LIBRARY_PATH. The real executable will be generated on this other folder:

$ file apps/.libs/gdalinfo
apps/.libs/gdalinfo: Mach-O 64-bit executable x86_64

But once you run "make install" the makefiles will generated a "clean" distribution folder where the executable are real executables.

In either way, with or without libtool, the key point is that DYLD_LIBRARY_PATH on MacOS is becoming deprecated or even useless as it is preceded by whatever "install_name_tool" defines.

One tools that you can use to figure out where the executable is getting the shared libraries from is "otool", for example:

$ otool -L apps/.libs/gdalinfo

And then I believe you can use "install_name_path" to delete the rpath that you disagree with. Maybe DYLD_LIBRARY_PATH will work then. If you really need.

That is my experience with setdevenv.sh on MacOS in regard to the DYLD_LIBRARY_PATH variable.

I am sure you can find a lot of discussions on that theme over the web, for example

https://superuser.com/questions/282450/where-do-i-set-dyld-library-path-on-mac-os-x-and-is-it-a-good-idea

https://blogs.oracle.com/dipol/dynamic-libraries,-rpath,-and-mac-os

Good luck,

Ivan







________________________________
From: gdal-dev <gdal-dev-bounces at lists.osgeo.org> on behalf of Alan Stewart <astewart at terragotech.com>
Sent: Tuesday, January 15, 2019 2:00 PM
To: Even Rouault
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] osx compile failure

Disabling SIP makes no difference.

Alan Stewart
Senior Software Engineer
TerraGo Technologies
3200 Windy Hill Road, Suite 1550W
Atlanta, GA 30339 USA
O.  +1 678.391.9615

www.terragotech.com<http://www.terragotech.com>

-----Original Message-----
From: Even Rouault <even.rouault at spatialys.com>
Sent: Monday, January 14, 2019 3:38 PM
To: Alan Stewart <astewart at terragotech.com>
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] osx compile failure

On lundi 14 janvier 2019 20:25:42 CET Alan Stewart wrote:
> DYLD_LIBRARY_PATH

Maybe an effect of the SIP thing you'd need to disable ?
https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html

--
Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190116/f10264ce/attachment-0001.html>


More information about the gdal-dev mailing list