[gdal-dev] #include tiffio.h in gtiff/libgeotiff/

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] #include tiffio.h in gtiff/libgeotiff/

Ari Jolma-2
The file frmts/gtiff/libgeotiff/xtiffio.h #include's "tiffio.h", which
is in frmts/gtiff/libtiff. However, when compiling in this directory
frmts/gtiff/libtiff is not included.

In my Linux Mint the compiler picks up tiffio.h from
/usr/include/x86_64-linux-gnu/ but when I compile in freebsd I get
./xtiffio.h:10:10: fatal error: 'tiffio.h' file not found

This was caught by a CPAN tester testing Alien::gdal (a Perl package
which downloads and compiles GDAL):
http://www.cpantesters.org/cpan/report/0903f568-3e0e-11e8-a1cf-bb670eaac09d

Am I missing something or is this a bug / configuration error?

Ari


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: #include tiffio.h in gtiff/libgeotiff/

Ari Jolma-2
It seems to me that frmts/gtiff/libgeotiff/GNUmakefile should also
override the default rule for %.$(OBJ_EXT) in GDALmake.opt

%.$(OBJ_EXT):    %.c
     $(CC) $(GDAL_INCLUDE) $(ALL_C_FLAGS) -c -o $@ $<

in addition to the rule for ../../o/%.$(OBJ_EXT)

BTW, could somebody explain why the two sets of .lo and .o: one in
current directory and one in ../../frmts/o?

Ari

On 12.04.2018 09:56, Ari Jolma wrote:

> The file frmts/gtiff/libgeotiff/xtiffio.h #include's "tiffio.h", which
> is in frmts/gtiff/libtiff. However, when compiling in this directory
> frmts/gtiff/libtiff is not included.
>
> In my Linux Mint the compiler picks up tiffio.h from
> /usr/include/x86_64-linux-gnu/ but when I compile in freebsd I get
> ./xtiffio.h:10:10: fatal error: 'tiffio.h' file not found
>
> This was caught by a CPAN tester testing Alien::gdal (a Perl package
> which downloads and compiles GDAL):
> http://www.cpantesters.org/cpan/report/0903f568-3e0e-11e8-a1cf-bb670eaac09d
>
> Am I missing something or is this a bug / configuration error?
>
> Ari
>
>

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: #include tiffio.h in gtiff/libgeotiff/

Even Rouault-2
In reply to this post by Ari Jolma-2
On jeudi 12 avril 2018 09:56:35 CEST Ari Jolma wrote:
> The file frmts/gtiff/libgeotiff/xtiffio.h #include's "tiffio.h", which
> is in frmts/gtiff/libtiff. However, when compiling in this directory
> frmts/gtiff/libtiff is not included.

I presume the libtiff.so must be present on the system, but not the TIFF
headers. Likely development package of libtiff missing.
GDAL's configure apparently only check the presence of the .so but doens't
check that the header is available.
Internal tiffio.h is included by internal libgeotiff if GDAL detects use of
internal libtiff (TIFF_SETTING=internal in GDALmake.opt)
But it wouldn't be correct for the internal libgeotiff to include the internal
tiffio.h and linking against external libgeotiff.

So the immediate fix is make sure libtiff headers are present on the system
(or explicitly select internal libtiff in ./configure)
And an improvement in configure.ac would be also welcome to check that the
headers of external libtiff are available.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: #include tiffio.h in gtiff/libgeotiff/

Ari Jolma-2
On 12.04.2018 19:25, Even Rouault wrote:
> On jeudi 12 avril 2018 09:56:35 CEST Ari Jolma wrote:
>> The file frmts/gtiff/libgeotiff/xtiffio.h #include's "tiffio.h", which
>> is in frmts/gtiff/libtiff. However, when compiling in this directory
>> frmts/gtiff/libtiff is not included.
> I presume the libtiff.so must be present on the system, but not the TIFF
> headers.

More likely the libtiff.a since compiling the conftest.c tests for it
(with -ltiff). In Linux Mint that would mean a broken libtiff-dev
package - at least that's how I can reproduce the case in it.
Interesting that a such situation should exist in a FreeBSD test
environment.

>   Likely development package of libtiff missing.
> GDAL's configure apparently only check the presence of the .so but doens't
> check that the header is available.

Yes.

> Internal tiffio.h is included by internal libgeotiff if GDAL detects use of
> internal libtiff (TIFF_SETTING=internal in GDALmake.opt)
> But it wouldn't be correct for the internal libgeotiff to include the internal
> tiffio.h and linking against external libgeotiff.

I guess in this case the best way is to explicitly set
--with-libtiff=internal.


>
> So the immediate fix is make sure libtiff headers are present on the system
> (or explicitly select internal libtiff in ./configure)
> And an improvement in configure.ac would be also welcome to check that the
> headers of external libtiff are available.

Maybe AC_CHECK_HEADER could be used in addition.

BTW, interestingly the "Check if user requests renaming internal
libgeotiff symbols" seems to appear twice in the configure.ac.

>
> Even
>

Thanks,

Ari

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev