* 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  make                3.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/

Attachment: mine-is-bigger.bz2
Description: Binary data

Reply via email to