Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#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)

patch (366 bytes) - added by kiorky 11 years ago.
patch for LDFLAGS

Download all attachments as: .zip

Change History (14)

comment:1 Changed 11 years ago by dron

Cc: dron added

Three problems were found during investigating #1927:

  1. If compiler flags are being picked up from user input (e.g. using 'CFLAGS="-mtune=v9 -m64" CXXFLAGS="-mtune=v9 -m64" ./configure' command) then they are only used when CFG variable does not contain "debug". For "debug" builds user supplied flags are ignored.

Workaround is to use 'CC="gcc -mtune=v9 -m64" CXX="g++ -mtune=v9 -m64" ./configure', in this case everything is used as it should.

  1. Some flags from compilation mode also should be used in linking mode. It seems that GCC (3.3.2 at least) does not understand whether it links 64-bit or 32-bit application without option. AFAIK, Sun linker deduces final format from the format of the first object file. This means we should propagate "-m64" option to linker, LNK_FLAGS can be used here. I am not sure whether it is safe to use CFLAGS contents directly. Probably we should pick up the LDFLAGS variable from user's input and add its contents to LNK_FLAGS.

Current workaround is the the same as in previous case.

  1. USER_PREFS variable has a limited usage. It can't be used to switch 32-/64-bit modes, for example, because it comes after configure, and configure script should test compilers, compiler options and external libraries first. USER_PREFS works on make stage and build process can fail because of linking 32-bit library (autodetected by configure) to 64-bit application (enabled later via USER_PREFS).

Best regards, Andrey

comment:2 Changed 11 years ago by Mateusz Łoskot

Milestone: 1.5.0

comment:3 Changed 11 years ago by Mateusz Łoskot

Owner: changed from warmerdam to Mateusz Łoskot
Status: newassigned

I fixed the first issue Andrey reported, compilation flags in debug mode (r13129)

comment:4 Changed 11 years ago by warmerdam

Cc: warmerdam 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:5 Changed 11 years ago by hobu

#2014 is related to this issue.

comment:6 Changed 11 years ago by hobu

Status on this one? Fixed for 1.5? Needs to be deferred?

comment:7 Changed 11 years ago by Mateusz Łoskot

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 Changed 11 years ago by Mateusz Łoskot

Resolution: fixed
Status: assignedclosed

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 Changed 11 years ago by kiorky

Milestone: 1.5.11.4.5
Resolution: fixed
Status: closedreopened

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

Changed 11 years ago by kiorky

Attachment: patch added

patch for LDFLAGS

comment:10 Changed 11 years ago by mloskot

Status: reopenednew

comment:11 Changed 11 years ago by mloskot

Status: newassigned

comment:12 Changed 11 years ago by Mateusz Łoskot

Resolution: fixed
Status: assignedclosed

The LNK_FLAGS has been removed (r13224) and replaced with user space flags LDFLAGS (r13415)

comment:13 Changed 11 years ago by Mateusz Łoskot

Milestone: 1.4.51.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.

Note: See TracTickets for help on using tickets.