#1966 closed defect (fixed)
Build Issues on Mac OS X
Reported by: | mhearne | Owned by: | Mateusz Łoskot |
---|---|---|---|
Priority: | normal | Milestone: | 1.4.4 |
Component: | ConfigBuild | Version: | 1.4.3 |
Severity: | normal | Keywords: | macos odbc |
Cc: | warmerdam |
Description
When attempting to build GDAL on my Mac, I get errors relating to ODBC.
The errors seem to stem from an attempt to include a header file called "odbcinst.h", which I cannot find in the GDAL distribution or on my system. Attempting to build without ODBC support results in errors relating to TIFF. I suspect that there is either something strange in my system configuration, or that build support for OS X needs some work.
Attached are the console results of running make, and the GDALmake.opt file.
Attachments (2)
Change History (11)
by , 17 years ago
Attachment: | GDALmake.opt added |
---|
comment:1 by , 17 years ago
Cc: | added |
---|---|
Component: | default → ConfigBuild |
Keywords: | macos odbc added |
Milestone: | → 1.4.4 |
Owner: | changed from | to
Mateusz,
Can you look into this? If it is a newly introduced problem in 1.4.3 then we definately want to address it for 1.4.3. Otherwise feel free to move it to 1.5.0 if the problem and or fix seems messy.
MHearne,
could you add a note on what version of MacOS X you are building on? I didn't have this problem on my oldish MacOS X system.
comment:2 by , 17 years ago
My platform information:
Darwin Kernel Version 8.10.1 i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363)
Incidentally, I see the same build problem on all versions of gdal (back to 1.4.0) that I can find on the web.
--Mike
comment:3 by , 16 years ago
I had somebody else in my office (also using a Mac) try the same thing, and predictably, it worked just fine. I compared his GDALmake.opt file with mine and they are significantly different in certain key areas, most notably in the "LIBS" build macro. His looks like this: LIBS = -lz -ldl $(DWG_LIBS) $(SDE_LIB) $(CURL_LIB) $(IDB_LIB)
whereas mine looks like this: LIBS = -L/sw/lib -lgeos -lgeos_c -lodbc -lodbcinst -lhdf5 -logdi31 -lgif -ltiff -lnetcdf -lcfitsio -lpq -L/sw/lib -lpq -lz -ldl $(DWG_LIBS) $(SDE_LIB) $(CURL_LIB) $(IDB_LIB)
I think the problem is that I have a bunch of stuff already installed on my system.
Is there some way to tell configure to ignore the universe of libraries that are installed on my system, and only use the stuff that's included in the tarball?
comment:4 by , 16 years ago
Status: | new → assigned |
---|
I don't know any way how to ignore system-wide libraries other than reordering -L/... paths but it's not supposed to solve all problems.
As I understand, the very first issues was about missing odbcinst.h file. This file is supposed to be installed with ODBC support on your Mac (unixODBC or iODBC). I'm wondering why ./configure detects ODBC on your machine. Does it mean you have ODBC package installed? If you do, then you should also have odbcinst.h header file installed in your system. So, my suggestion is to:
- re-check if ./configure detects ODBC support (see what it says in the summary output)
- search your file system for odbcinst.h and see where it is installed
You are writing that if you disable ODBC then you're getting TIFF problems. What are these problems? Does the ./configure fail or you are getting compilation errors? Perhaps you have libtiff installed already in your system and its version is incompatible with GDAL, then try to tell GDAL building system to use internal copy of libtiff:
./configure --with-libtiff=internal
If you don't need ODBC support, then you can try something like this:
./configure --with-libtiff=internal --with-geotiff=internal --with-odbc=no
comment:5 by , 16 years ago
I got the compile to work by modifying my co-worker's GDALmake.opt file. Unfortunately, when I try to import the gdal python module (my whole goal in getting this built), I get the following error:
Fatal Python error: Interpreter not initialized (version mismatch?) Abort trap
I inserted a print statement into /usr/local/lib/python2.5/site-packages/gdal.py
and it's happening on the import of _gdal.
Should I submit this as a new bug, or just give up in abject despair?
--Mike
comment:6 by , 16 years ago
Mike,
You are probably using different version of Python than GDAL bindings linked against to. For examaple, GDAL bindings are linked against Python 2.4 and you use Python 2.5 interpreter.
Can I assume the Mac OS X issue is gone and it works for you?
comment:7 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I'm taking the liberty to close this ticket as fixed.
comment:8 by , 16 years ago
Actually, I still have the import problem, I just haven't had time to look into it more.
And your assumption is incorrect - I'm building against the same version as the interpreter I'm running.
My suspicion is that I have a bunch of fink gdal and other related libraries installed here and there, and somehow that confused either the build process, or the import process. When I have more time, I'll do some cleaning of old libraries, and start fresh.
--Mike
Make options file