lib/raster/gdal.c – missing libgdal.20.dylib in the GDAL library names list

[vince]

static void load_library(void)
{
    static const char *const candidates[] = {
# ifdef __unix__
    "libgdal.so.20",
    "libgdal.so.1",
    "libgdal.1.1.so",
    "gdal.1.0.so",
    "gdal.so.1.0",
    "libgdal.so",
    "libgdal1.6.0.so",
    "libgdal1.7.0.so",
# endif

Humm… where is “libgdal.20.dylib” for poor MacOS X users?

Shame on you! :P :P

[martinl]

Based on (1) correct identification is

__APPLE__ && __MACH__

or

__APPLE__

is enough?

(1) ​https://sourceforge.net/p/predef/wiki/OperatingSystems/

[vince]

Will try and let you know. Thanks for your reactivity

[vince]

test.c:

#include <stdio.h>

int main (int argc, char * argv []) {

#ifdef __APPLE__
    printf ("Apple!\n");
#else
    print ("Something else. Yuck :P\n");
#endif
}

Air > clang -o test test.c
Air > ./test
Apple!

[martinl]

Replying to vince:

Will try and let you know. Thanks for your reactivity

really for my reactivity? No, thanks :-)

[vince]

Woops, sorry. I didn’t mean you were sour. :P Sometimes when I’m tuckered some French words manage to seep in.

I’m still stuck though. Adding the dylib name won’t suffice, as MacOS X doesn’t define LD_LIBRARY_PATH, so the whole path is needed.

Isn’t there a way to define default library paths at compile time?

[vince]

By the way, _ _unix_ _ is not defined by clang on MacOS, so I have to replace all occurrences of _ _unix_ _ by _ _APPLE_ _. It would be nice to have both in the code…

[neteler]

Since GDAL 2.3.0 is due soon, I was wondering how up-to-date the code in question is:

lib/raster/gdal.c

static void load_library(void)
{
    static const char *const candidates[] = {
# ifdef __unix__
	"libgdal.so.20",
	"libgdal.so.1",
	"libgdal.1.1.so",
	"gdal.1.0.so",
	"gdal.so.1.0",
	"libgdal.so",
	"libgdal1.6.0.so",
	"libgdal1.7.0.so",
# endif
# ifdef _WIN32
	"gdal202.dll",        
	"gdal201.dll",
	"gdal200.dll",
	"gdal111.dll",
	"gdal110.dll",
	"gdal19.dll",
	"gdal18.dll",
	"gdal17.dll",
	"gdal16.dll",
	"gdal15.dll",
	"gdal11.dll",
	"gdal.1.0.dll",
	"libgdal-1.dll",
	"gdal.dll",
# endif
	NULL
    };
    int i;

This ticket is still open, so probably it should be all revisited now.

[neteler]

Replying to neteler:

Since GDAL 2.3.0 is due soon, I was wondering how up-to-date the code in question is:

lib/raster/gdal.c

... any suggestion? This is now rather imminent.

[neteler]

gdal203.dll was added in r73573:73575

Not sure about other needed changes?

# ifdef __unix__

seems to be lagging behind?

@cmbarton: what about MacOS? Should libgdal.20.dylib or similar be added?

[neteler]

Ticket retargeted after milestone closed

[martinl]

Bump milestone to 7.4.4

[neteler]

Ticket retargeted after milestone closed

[vince]

This hasn't been corrected in 7.6 :(

Also, I think the smartest way to handle this is to make the configure script record the proper path to the GDAL library using gdal-config. Once the access path is known, there is no need for that (silly?) function enumerating all possible names and forgetting about some.

Also more ifdef APPLE are needed here and there in the same file.

[neteler]

@vince: do you see a chance to provide a patch?

[vince]

Yes, I could probably do that within a few days, if you’re willing to integrate it.

[neteler]

Replying to vince:

Yes, I could probably do that within a few days, if you’re willing to integrate it.

Problem solving contributions are always welcome :-)