#1929 closed defect (fixed)
Missing compilation and linking flags on Unix
Reported by: | Mateusz Łoskot | Owned by: | Mateusz Łoskot |
---|---|---|---|
Priority: | normal | Milestone: | 1.5.2 |
Component: | ConfigBuild | Version: | svn-trunk |
Severity: | normal | Keywords: | compilation linker cxxflags cflags ldflags |
Cc: | dron, warmerdam |
Description
This is a kind general defect report about dedicated to discussion about missing and incorrect compilation and linking flags in GDAL building system for Unix platforms.
Recently, number of issues have been identified like CXXFLAGS and CFLAGS ignored while building GDAL in debug (CFG=debug) and profiling mode. There are also some flags missing for linker, etc.
Please, include all issues related to this report in comments.
Originally, investigation of this defect has been triggered by Ticket #1927
Attachments (1)
Change History (14)
comment:1 by , 16 years ago
Cc: | added |
---|
comment:2 by , 16 years ago
Milestone: | → 1.5.0 |
---|
comment:3 by , 16 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
I fixed the first issue Andrey reported, compilation flags in debug mode (r13129)
comment:4 by , 16 years ago
Cc: | added |
---|
r13129 results in default CFLAGS values (ie. -O) leaking into the flags used when CFG=debug.
Since CFG=debug is now partially broken, I'd suggest rushing ahead to strip out the CFG based behavior and go to a more normal CFLAGS/CXXFLAGS based behavior.
comment:7 by , 16 years ago
I believe it's been mostly fixed. Although I suppose the remaining issue could be that one mentioned above by Andrey about pick up the LDFLAGS variable from user's input and add its contents to LNK_FLAGS. Is that true?
comment:8 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I applied fix for the 2nd issue pointed by Andrey (trunk - r13415 and branches/1.5 - r13416).
Now, GDALmake.opt grabs LDFLAGS from user's input:
export LDFLAGS="..." ./configure
and passes it to linker commands for libgdal and applications.
I also removed duplicated input of libgdal.a from $(GDAL_SLIB) target:
g++ -dynamiclib /Users/mloskot/dev/gdal/_svn/trunk/gdal/frmts/o/*.o ... ./ogr/gml2ogrgeometry.o /Users/mloskot/dev/gdal/_svn/trunk/gdal/libgdal.a /Users/mloskot/dev/gdal/_svn/trunk/gdal/libgdal.a -L/usr/local/lib -lgeos_c -I/usr/include -lsqlite3 -L/usr/local/lib -lexpat -lNCSEcw -lNCSCnet -lNCSUtil -ljasper -ljpeg -lnetcdf -lz -ldl-L/usr/lib -lcurl -lssl -lcrypto -lz -o /Users/mloskot/dev/gdal/_svn/trunk/gdal/libgdal.dylib
I've not added full support of USER_PREFS as, following Andrey's analysis, it has limited usage. So, I assume this issue has been fixed and I'm closing this ticket as fixed. Also, I'm going to close the sister-ticket #1927.
comment:9 by , 16 years ago
Milestone: | 1.5.1 → 1.4.5 |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
It is not fixed in the 1.4 branch. See the makefile there: http://trac.osgeo.org/gdal/browser/branches/1.4/gdal/GDALmake.opt.in
comment:10 by , 16 years ago
Status: | reopened → new |
---|
comment:11 by , 16 years ago
Status: | new → assigned |
---|
comment:12 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:13 by , 16 years ago
Milestone: | 1.4.5 → 1.5.2 |
---|
Unfortunately, there has been a number of separate commits in trunk that were fixing various compiler and linker flags. I'm sorry, but unable to get the GDALmake.opt and makefile safely synchronized back to branches/1.4. Because these fixes are available in branches/1.5, I'm updating milestone to 1.5.
Three problems were found during investigating #1927:
Workaround is to use 'CC="gcc -mtune=v9 -m64" CXX="g++ -mtune=v9 -m64" ./configure', in this case everything is used as it should.
Current workaround is the the same as in previous case.
Best regards, Andrey