Bug#358943: FTBFS on AMD64: undefined reference to `InsertFileName'
package libpano12 tags 358943 + confirmed upstream retitle 358943 FTBFS when JAVA can't be found: undefined reference to `InsertFileName' thanks Le Mardi 28 Mars 2006 06:36, Martin Michlmayr a écrit : [...] Oh, I wouldn't leave the bug open for that. Once 4.1 is the default, I'm sure people are told... I'd only leave the bug open if the configure script is buggy (saying it doesn't do java but then doing something to fail when there's no java). I was busy since you reported this bug, and I didn't have the time to investigate/report it upstream. But, today I saw this on upstream mailing-lists : http://sourceforge.net/mailarchive/forum.php?thread_id=10817946forum_id=36988 -- Florent pgpyGAT0J5Pab.pgp Description: PGP signature
Bug#358943: FTBFS on AMD64: undefined reference to `InsertFileName'
Le Lundi 27 Mars 2006 03:18, Martin Michlmayr a écrit : * Florent Bayle [EMAIL PROTECTED] [2006-03-27 00:46]: Someone tried for me to build my package on a sid chroot on amd64, and it seems to work (build log is attached). Could you please describe more precisely your build environment (gcc version for instance), are you still able to reproduce the bug ? Oh, I'm happy to show you mine given that you have shown me yours. :-P It was a pleasure... :-D Comparing the build logs is really interesting. Oh, hmm, this seems to be a GCC 4.1 bug after all... one I've seen in some other packages but haven't had time to investigate. But this is strang bcause I'm pretty sure I've seen the problem when I tried with 4.0 too. But I'm not sure. Anyway, I think there's still a bug in the software (upstream). Observations: - First, a make clean doesn't work here, but I've no idea why. - Second, on your box Java is recognized whereas on mine it isn.t' There might be more but these are so obvious that I didn't start looking further. I had the time to investigate, and I was able to reproduce the bug on x86. The following is from diff your-log mylog 1: /usr/bin/make clean -make[1]: Entering directory `/home/plop/libpano12-2.8.0' -Making clean in build -make[2]: Entering directory `/home/plop/libpano12-2.8.0/build' -Making clean in win32 -make[3]: Entering directory `/home/plop/libpano12-2.8.0/build/win32' ... -make[1]: Leaving directory `/home/plop/libpano12-2.8.0' +make[1]: Entering directory `/build/tbm/libpano12-2.8.0' +make[1]: *** No rule to make target `clean'. Stop. +make[1]: Leaving directory `/build/tbm/libpano12-2.8.0' +make: [clean] Error 2 (ignored) rm -rf config.status config.log .deps/ tools/.deps/ \ m4/Makefile doc/Makefile Makefile build/Makefile \ build/win32/Makefile tools/Makefile \ config.h stamp-h1 libtool dh_clean Huh? ii make3.80+3.81.rc2-1 The GNU version of the make utility. (sid)1427:[EMAIL PROTECTED]: ~/src/libpano12-2.8.0] grep ^clean: debian/rules clean: (sid)1428:[EMAIL PROTECTED]: ~/src/libpano12-2.8.0] It try to make clean in libpano12-2.8.0/, so if you don't have libpano12-2.8.0/Makefile it will fail (this file is created by the configure). For some reasons, I have the Makefile, and you've not. I think that it's not a bug since the error is ignored. 2: configure: cannot find the java directory, assuming it is specified in CFLAGS -checking if JAVA package is complete... yes +checking if JAVA package is complete... no +configure: WARNING: java will not be used! PTEditor and PTPicker support disabled checking for ZLIB support ... Looking at config.log I see: configure:19975: cannot find the java directory, assuming it is specified in CFLAGS configure:20018: gcc -c -g -O2 -I/ conftest.c 5 conftest.c:23:17: error: jni.h: No such file or directory configure:20024: $? = 1 This is a program when using GCC 4.1 which I haven't had time to investigate yet. Maybe a missing dependency or a missing -I or something. This bug happens when you build with : - gcc 4.0 and gcj 4.1/libgcj7-dev - gcc 4.1 and gcj 4.0/libgcj6-dev. But it doesn't happens if you build with : - gcc 4.1 and gcj 4.1/libgcj7-dev - gcc 4.0 and gcj 4.0/libgcj6-dev. So if you want to build it with gcc-4.1, you need to have gcj 4.1/libgcj7-dev installed (and to modify the debian/control). However, I'd say this is still an (upstream bug): it is looking for Java during configure, sees it is not complete, disables PTEditor and PTPicker, but then *still* seems to do something that requires some symbol that presumably comes from Java. Does that make sense? I don't know if it's a bug, because the option --with-java is passed to the ./configure, so as it's said in the log, it assume that the java directory is specified in CFLAGS. But I will nevertheless report it. I've attached my build log. Thanks. I think that I will let this but open until gcc 4.1 becomes the official gcc version in sid (I will upload a new version of the package depending on libgcj7-dev as soon as it will be the case). Thanks a lot for taking the time to report/investigate the bug. -- Florent pgpmFrgAcNpnl.pgp Description: PGP signature
Bug#358943: FTBFS on AMD64: undefined reference to `InsertFileName'
* Florent Bayle [EMAIL PROTECTED] [2006-03-27 19:11]: This bug happens when you build with : - gcc 4.0 and gcj 4.1/libgcj7-dev - gcc 4.1 and gcj 4.0/libgcj6-dev. But it doesn't happens if you build with : - gcc 4.1 and gcj 4.1/libgcj7-dev - gcc 4.0 and gcj 4.0/libgcj6-dev. So if you want to build it with gcc-4.1, you need to have gcj 4.1/libgcj7-dev installed (and to modify the debian/control). Good to know, thanks for investigating! Now I can re-try the other packages that failed with the jni.h error too... I didn't have time to investigate this problem yet, so thanks a lot for doing my work. :) I don't know if it's a bug, because the option --with-java is passed to the ./configure, so as it's said in the log, it assume that the java directory is specified in CFLAGS. But I will nevertheless report it. I think that I will let this but open until gcc 4.1 becomes the official gcc version in sid (I will upload a new version of the package depending on libgcj7-dev as soon as it will be the case). Oh, I wouldn't leave the bug open for that. Once 4.1 is the default, I'm sure people are told... I'd only leave the bug open if the configure script is buggy (saying it doesn't do java but then doing something to fail when there's no java). -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358943: FTBFS on AMD64: undefined reference to `InsertFileName'
Le Samedi 25 Mars 2006 13:07, Martin Michlmayr a écrit : Package: libpano12 Version: 2.8.0-1 Your package fails to build on AMD64. I cannot reproduce this problem on i386. Do you have any idea what might be the cause? [...] Hi, Someone tried for me to build my package on a sid chroot on amd64, and it seems to work (build log is attached). Could you please describe more precisely your build environment (gcc version for instance), are you still able to reproduce the bug ? Thanks. -- Florent dpkg-buildpackage: source package is libpano12 dpkg-buildpackage: source version is 2.8.0-1 dpkg-buildpackage: source changed by Florent Bayle [EMAIL PROTECTED] dpkg-buildpackage: host architecture amd64 debian/rules clean dh_testdir dh_testroot rm -f build-stamp configure-stamp # Commands to clean up after the build process. /usr/bin/make clean make[1]: Entering directory `/home/plop/libpano12-2.8.0' Making clean in build make[2]: Entering directory `/home/plop/libpano12-2.8.0/build' Making clean in win32 make[3]: Entering directory `/home/plop/libpano12-2.8.0/build/win32' rm -rf .libs _libs rm -f *.lo make[3]: Leaving directory `/home/plop/libpano12-2.8.0/build/win32' Making clean in . make[3]: Entering directory `/home/plop/libpano12-2.8.0/build' rm -rf .libs _libs rm -f *.lo make[3]: Leaving directory `/home/plop/libpano12-2.8.0/build' make[2]: Leaving directory `/home/plop/libpano12-2.8.0/build' Making clean in doc make[2]: Entering directory `/home/plop/libpano12-2.8.0/doc' rm -rf .libs _libs rm -f *.lo make[2]: Leaving directory `/home/plop/libpano12-2.8.0/doc' Making clean in tools make[2]: Entering directory `/home/plop/libpano12-2.8.0/tools' rm -f panoinfo panoinfo rm -f PTOptimizer PTOptimizer rm -f PTmender PTmender rm -f PTblender PTblender rm -f PTtiff2psd PTtiff2psd rm -rf .libs _libs rm -f *.o rm -f *.lo make[2]: Leaving directory `/home/plop/libpano12-2.8.0/tools' Making clean in m4 make[2]: Entering directory `/home/plop/libpano12-2.8.0/m4' rm -rf .libs _libs rm -f *.lo make[2]: Leaving directory `/home/plop/libpano12-2.8.0/m4' Making clean in . make[2]: Entering directory `/home/plop/libpano12-2.8.0' test -z libpano12.la || rm -f libpano12.la rm -f ./so_locations rm -rf .libs _libs rm -f *.o rm -f *.lo make[2]: Leaving directory `/home/plop/libpano12-2.8.0' make[1]: Leaving directory `/home/plop/libpano12-2.8.0' rm -rf config.status config.log .deps/ tools/.deps/ \ m4/Makefile doc/Makefile Makefile build/Makefile \ build/win32/Makefile tools/Makefile \ config.h stamp-h1 libtool dh_clean dpkg-source -b libpano12-2.8.0 dpkg-source: building libpano12 using existing libpano12_2.8.0.orig.tar.gz dpkg-source: building libpano12 in libpano12_2.8.0-1.diff.gz dpkg-source: building libpano12 in libpano12_2.8.0-1.dsc debian/rules build dh_testdir # Commands to configure the package. ./configure --prefix=/usr --enable-shared --enable-static --with-jpeg --with-png --with-tiff --with-zlib --with-java --build x86_64-linux-gnu checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... x86_64-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E
Bug#358943: FTBFS on AMD64: undefined reference to `InsertFileName'
* Florent Bayle [EMAIL PROTECTED] [2006-03-27 00:46]: Someone tried for me to build my package on a sid chroot on amd64, and it seems to work (build log is attached). Could you please describe more precisely your build environment (gcc version for instance), are you still able to reproduce the bug ? Oh, I'm happy to show you mine given that you have shown me yours. :-P Comparing the build logs is really interesting. Oh, hmm, this seems to be a GCC 4.1 bug after all... one I've seen in some other packages but haven't had time to investigate. But this is strang bcause I'm pretty sure I've seen the problem when I tried with 4.0 too. But I'm not sure. Anyway, I think there's still a bug in the software (upstream). Observations: - First, a make clean doesn't work here, but I've no idea why. - Second, on your box Java is recognized whereas on mine it isn.t' There might be more but these are so obvious that I didn't start looking further. The following is from diff your-log mylog 1: /usr/bin/make clean -make[1]: Entering directory `/home/plop/libpano12-2.8.0' -Making clean in build -make[2]: Entering directory `/home/plop/libpano12-2.8.0/build' -Making clean in win32 -make[3]: Entering directory `/home/plop/libpano12-2.8.0/build/win32' ... -make[1]: Leaving directory `/home/plop/libpano12-2.8.0' +make[1]: Entering directory `/build/tbm/libpano12-2.8.0' +make[1]: *** No rule to make target `clean'. Stop. +make[1]: Leaving directory `/build/tbm/libpano12-2.8.0' +make: [clean] Error 2 (ignored) rm -rf config.status config.log .deps/ tools/.deps/ \ m4/Makefile doc/Makefile Makefile build/Makefile \ build/win32/Makefile tools/Makefile \ config.h stamp-h1 libtool dh_clean Huh? ii make3.80+3.81.rc2-1 The GNU version of the make utility. (sid)1427:[EMAIL PROTECTED]: ~/src/libpano12-2.8.0] grep ^clean: debian/rules clean: (sid)1428:[EMAIL PROTECTED]: ~/src/libpano12-2.8.0] 2: configure: cannot find the java directory, assuming it is specified in CFLAGS -checking if JAVA package is complete... yes +checking if JAVA package is complete... no +configure: WARNING: java will not be used! PTEditor and PTPicker support disabled checking for ZLIB support ... Looking at config.log I see: configure:19975: cannot find the java directory, assuming it is specified in CFLAGS configure:20018: gcc -c -g -O2 -I/ conftest.c 5 conftest.c:23:17: error: jni.h: No such file or directory configure:20024: $? = 1 This is a program when using GCC 4.1 which I haven't had time to investigate yet. Maybe a missing dependency or a missing -I or something. However, I'd say this is still an (upstream bug): it is looking for Java during configure, sees it is not complete, disables PTEditor and PTPicker, but then *still* seems to do something that requires some symbol that presumably comes from Java. Does that make sense? I've attached my build log. -- Martin Michlmayr http://www.cyrius.com/ mine-is-bigger.bz2 Description: Binary data
Bug#358943: FTBFS on AMD64: undefined reference to `InsertFileName'
Package: libpano12 Version: 2.8.0-1 Your package fails to build on AMD64. I cannot reproduce this problem on i386. Do you have any idea what might be the cause? Automatic build of libpano12_2.8.0-1 on em64t by sbuild/amd64 1.106 ... if gcc -DHAVE_CONFIG_H -I. -I.. -D__Ansi__=1 -DHasTIFF -DHasJPEG -g -O2 -MT PTcommon.o -MD -MP -MF .deps/PTcommon.Tpo -c -o PTcommon.o PTcommon.c; \ then mv -f .deps/PTcommon.Tpo .deps/PTcommon.Po; else rm -f .deps/PTcommon.Tpo; exit 1; fi /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -L.. -o PTmender PTmender.o ColourBrightness.o PTcommon.o -lpano12 -ljpeg -ltiff gcc -g -O2 -o .libs/PTmender PTmender.o ColourBrightness.o PTcommon.o -L/build/tbm/libpano12-2.8.0 /build/tbm/libpano12-2.8.0/.libs/libpano12.so -lpng /usr/lib/libtiff.so /usr/lib/libjpeg.so -lz -lm -lc -Wl,--rpath -Wl,/usr/lib PTmender.o: In function `main':/build/tbm/libpano12-2.8.0/tools/PTmender.c:276: undefined reference to `InsertFileName' :/build/tbm/libpano12-2.8.0/tools/PTmender.c:344: undefined reference to `InsertFileName' collect2: ld returned 1 exit status make[3]: *** [PTmender] Error 1 -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
