Ticket #1929 (closed defect: fixed)

Opened 7 months ago

Last modified 1 day ago

Missing compilation and linking flags on Unix

Reported by: mloskot Assigned to: mloskot
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

patch (366 bytes) - added by kiorky on 02/09/08 16:32:17.
patch for LDFLAGS

Change History

10/22/07 10:41:40 changed by dron

  • cc set to dron.

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.

2. 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.

3. 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

10/24/07 20:35:11 changed by mloskot

  • milestone set to 1.5.0.

11/28/07 10:30:42 changed by mloskot

  • status changed from new to assigned.
  • owner changed from warmerdam to mloskot.

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

11/29/07 11:10:05 changed by warmerdam

  • cc changed from dron to dron, warmerdam.

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.

12/03/07 22:41:46 changed by hobu

#2014 is related to this issue.

12/18/07 13:19:22 changed by hobu

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

12/20/07 08:10:10 changed by mloskot

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?

12/20/07 22:24:50 changed by mloskot

  • status changed from assigned to closed.
  • resolution set to fixed.

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.

02/09/08 16:20:36 changed by kiorky

  • status changed from closed to reopened.
  • resolution deleted.
  • milestone changed from 1.5.1 to 1.4.5.

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

02/09/08 16:32:17 changed by kiorky

  • attachment patch added.

patch for LDFLAGS

05/08/08 06:10:56 changed by mloskot

  • status changed from reopened to new.
  • owner changed from mloskot to mloskot.

05/08/08 06:11:05 changed by mloskot

  • status changed from new to assigned.
  • owner changed from mloskot to mloskot.

05/10/08 14:20:05 changed by mloskot

  • status changed from assigned to closed.
  • resolution set to fixed.

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

05/10/08 14:26:16 changed by mloskot

  • milestone changed from 1.4.5 to 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.