Opened 9 years ago

Closed 9 years ago

#6012 closed enhancement (fixed)

Add plugin option to some drivers makefile

Reported by: ilucena Owned by: warmerdam
Priority: normal Milestone:
Component: default Version: unspecified
Severity: normal Keywords: makefiles
Cc: antonio

Description

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.

Change History (14)

comment:1 by antonio, 9 years ago

Cc: antonio added
Version: unspecified

comment:2 by ilucena, 9 years ago

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?

comment:3 by ilucena, 9 years ago

HDF4 GNUmakefile fixed on #29427.

comment:4 by Even Rouault, 9 years ago

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.

comment:5 by ilucena, 9 years ago

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.

comment:6 by Even Rouault, 9 years ago

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.

comment:7 by ilucena, 9 years ago

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.

comment:8 by Even Rouault, 9 years ago

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

comment:9 by ilucena, 9 years ago

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

comment:10 by ilucena, 9 years ago

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

in reply to:  10 comment:11 by Even Rouault, 9 years ago

Replying to ilucena:

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

Looks good to me.

comment:12 by ilucena, 9 years ago

Even,

Can I go ahead and backport that to 2.0?

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

Thanks.

in reply to:  12 comment:13 by Even Rouault, 9 years ago

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.

comment:14 by ilucena, 9 years ago

Resolution: fixed
Status: newclosed

Done r29501 Thanks.

Note: See TracTickets for help on using tickets.