[Gdal-dev] static libraries revamped (was: new build strategy for org/orgsf_frmts/)

Amici Alessandro alessandro_amici at telespazio.it
Thu Jul 24 10:56:56 EDT 2003

> Alessandro,
> While I don't quite understand the approach, my impression is this
> use of "ld -r" for partial linking is going to be problematic on
> some platforms.  As such, I do not think we should be making the GDAL
> build mechanism depend on it.
> Can be find another approach?


i see two possibilities:
1 - create an 'ogr/o' directory and move the library object there (same
trick used
	in the frmts directories) -> GDAL_OBJ += ogr/o/*.o
2 - move the executables into an 'apps' directory and probably the library
	in a 'ocore' (or something like that) directory -> GDAL_OBJ +=

i wuold prefer the second solution, but moving the files in cvs is not nice,
you do. so, i'll bite the dust and implement solution n. 1 ASAP.

the reason i preferred the partial linking approach is that you avoid the
'*' wild
card in the dependencies. note that all the '$(MAKE) check-lib' logic is due
to *.o
having different meaning at the beginning and at the end of the build.
changing the configuration and rebuilding may result in stale object files
inside the libray if you don't 'make clean' properly.

so i think it has been a valuable quest... :(

ok, back to work:
- a libtool patch is in the works
- since i put my hands on a 4-way itanium2, i have the strong feeling that
	with -j 4 is a good thing (read: gdal parallel build is broken!
looking into it)


More information about the Gdal-dev mailing list