Add plugin option to some drivers makefile

[ilucena]

Some drivers do not not have the option to be build as plugins or either because the makefile doesn't have that options or because it is broken.

On Linux, for example, the HDF5 doesn't have a "plugin" section at all. While the HDF4 drivers does have "plugin" but it seems to be broken.

I am willing to updates some of those makefile and/or send patches as long as it is convenient to the maintainers of those drivers.

[ilucena]

For HDF4 GNUmakefile what seems to be missing is $(GDAL_INCLUDE) on CPPFLAGS but there is also this error that comes from the linker:

/usr/bin/ld: hdf4dataset.o: relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
hdf4dataset.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [gdal_HDF4.so] Error 1

I can add -fPIC to CPPFLAGS and that problem is gone but why this is not a problem when building the HDF4 driver internally to the main GDAL shared library?

[ilucena]

HDF4 GNUmakefile fixed on #29427.

[Even Rouault]

Ivan,

I'm not completely sure your change is appropriate. For me, HDF4 plugin buildings succeeds for a non libtool build without your changes : CXXFLAGS already includes -fPIC, and GDAL_INCLUDE is also added by the following rule of GDALmake.opt

%.$(OBJ_EXT): %.cpp

$(CXX) $(GDAL_INCLUDE) $(CXXFLAGS) $(CPPFLAGS) -c -o $@ $<

And I'm wondering if all compilers would like -fPIC (thinking to non-GCC non-Clang) put like that unconditionnaly.

Regarding the process: changes should always go to trunk, and then only to stable branch when they are safe.

[ilucena]

Even,

I am sorry, I thought I was working on trunk. Should I retract those change to 2.0?

Like I put on my comment, that is a little confusing. It seems like that rules does not apply when running "make plugin". I am using libtool and g++ but I will try without libtool and with another compiler to see what happens.

[Even Rouault]

Yes, I'd prefer experimentations to be done in trunk (and ideally in local tree before ;-))

I have tried a bit with libtool, but the issues with plugin building were more fundamental. Basically LD_SHARED wasn't defined, so the compilation line began with "hdf4dataset.o" without any executable.

[ilucena]

Yes, I have the same experience. If I run ./configure --without-libtool the LD_SHARED is set to "g++ -shared" and works fine for driver that the GNUmakefile have plugin like HDF4.

That means the problem happens when we use libtool, so I will try not to.

So I will add the plugin section to hdf5 GNUmakefile (on the trunk) shortly.

Just out of curiosity, I also tied to build GDAL with Intel compiler, icc. The -fPIC is not the problem, the GDALmake.opt rules works just fine:

icc -I/home/ilucena/Dev/gdal/2.0/port -I/home/ilucena/Dev/gdal/2.0/gcore -I/home/ilucena/Dev/gdal/2.0/alg -I/home/ilucena/Dev/gdal/2.0/ogr -I/home/ilucena/Dev/gdal/2.0/ogr/ogrsf_frmts -g -O2 -fPIC  -Wall  -DOGR_ENABLED -I/Dev/gdal/2.0/port  -DGDAL_COMPILATION	 -I../frmts/zlib  -DHAVE_LIBZ -I/usr/include/libxml2 -DHAVE_LIBXML2 -c -o cpl_conv.o cpl_conv.cpp
i

But the LD_SHARED is set to "ld -shared" and results in errors:

/home/ilucena/Dev/gdal/2.0/frmts/o/cpcidskfile.o: In function `__sti__$E':
/usr/include/c++/4.4.7/iostream:72: undefined reference to `__dso_handle'
ld: /home/ilucena/Dev/gdal/2.0/frmts/o/cpcidskfile.o: relocation R_X86_64_PC32 against undefined hidden symbol `__dso_handle' can not be used when making a shared object
ld: final link failed: Bad value
make[1]: *** [/home/ilucena/Dev/gdal/2.0/libgdal.so] Error 1
make[1]: Leaving directory `/home/ilucena/Dev/gdal/2.0'
make: *** [check-lib] Error 2

But I don't need to use icc for now.

[Even Rouault]

Couldn't you add -fPIC only in the plugin build case ?

[ilucena]

Even,

There is no need to add -fPIC if running "./configure --without-libtool".

On r29462 I wrote the minimal change necessary to add the plugin option to a driver's GNUmakefile.

Note that $(SO_EXT) is needed to build shared libraries with proper extension on OSX, meaning ".dylib" instead of ".so".

I have a couple of other driver that I want to make that same change, so I am not closing the ticket just yet.

Thanks.

Ivan

[ilucena]

See r29463 for a bulk change on some GNUMakefile, adding "plugin" and "$(SO_EXT)".

[Even Rouault]

Replying to ilucena:

See r29463 for a bulk change on some GNUMakefile, adding "plugin" and "$(SO_EXT)".

Looks good to me.

[ilucena]

Even,

Can I go ahead and backport that to 2.0?

That would include the same changes as in r29463 and r29462.

Thanks.

[Even Rouault]

Replying to ilucena:

Even,

Can I go ahead and backport that to 2.0?

That would include the same changes as in r29463 and r29462.

Looks good to me

Thanks.

[ilucena]

Done r29501 Thanks.