Concurrent build bug?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Concurrent build bug?

Dalton, Tom-3
Concurrent build bug?

Hi,

I have had a search for this issue on the Trac and the mail list archives but couldn't find anything.

I am trying to build libgeotiff 1.2.5 using multiple concurrent build processes, but I think there is a subtle bug in the Makefile.in that misses a dependency. This results in the build failing sometimes, depending on how the scheduling works out.

I think that some of the files like geo_free.c/o rely on xtiffio.h

Xtiffio.h is a symlink and is removed and recreated by the ${XTIFFINC} rule.

Geo_free.o is created by it's own rule and is also contained in the ${OBJS} (via ${CORE_OBJS}) rules. However, none of these seem to contain the dependency on ${XTIFFINC}. The result seems to be that sometimes the XTIFFINC rule is interleaved with the building of the core objects, so you get something like:

rm xtiffio.h
gcc -c ….. Geo_free.c
ln -s ./libxtiff/*.h (which includes xtiffio.h)

So then the compilation fails because it can't find the xtiffio.h and the build bombs out. Running the build again with no changes will then work.

As a workaround, I can avoid the use of the -j flag (or use -j 1).

Is anyone familiar with the build files that can confirm or deny this is a bug?

Thanks for your help,

Tom Dalton


_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

Re: Concurrent build bug?

Howard Butler

On Sep 22, 2009, at 4:24 AM, Dalton, Tom wrote:

> Hi,
>
> I have had a search for this issue on the Trac and the mail list  
> archives but couldn't find anything.
>
> I am trying to build libgeotiff 1.2.5 using multiple concurrent  
> build processes, but I think there is a subtle bug in the  
> Makefile.in that misses a dependency. This results in the build  
> failing sometimes, depending on how the scheduling works out.
>
> I think that some of the files like geo_free.c/o rely on xtiffio.h
>
> Xtiffio.h is a symlink and is removed and recreated by the $
> {XTIFFINC} rule.
>
> Geo_free.o is created by it's own rule and is also contained in the $
> {OBJS} (via ${CORE_OBJS}) rules. However, none of these seem to  
> contain the dependency on ${XTIFFINC}. The result seems to be that  
> sometimes the XTIFFINC rule is interleaved with the building of the  
> core objects, so you get something like:
>
> rm xtiffio.h
> gcc -c ….. Geo_free.c
> ln -s ./libxtiff/*.h (which includes xtiffio.h)
>
> So then the compilation fails because it can't find the xtiffio.h  
> and the build bombs out. Running the build again with no changes  
> will then work.
>
> As a workaround, I can avoid the use of the -j flag (or use -j 1).
>
> Is anyone familiar with the build files that can confirm or deny  
> this is a bug?
>
> Thanks for your help,
>

Tom,

Can you try using the svn trunk?  I have reworked the build process to  
use a typical autoconf/automake setup which should support parallel  
builds properly.  Please let me know if you have trouble.

Thanks,

Howard
_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff