After doing the daily build of -STABLE, I boot it up, then run portupgrade -a (during the -STABLE build, I had already done a "cvs update" to the ports tree). (I do this within "script," in order to retain a record of what happened.) Here is a cut/paste from the beginning, then the end of the portupgrade run for lcms: ---> Upgrading 'lcms-1.12,1' to 'lcms-1.13,1' (graphics/lcms) ---> Building '/usr/ports/graphics/lcms' ===> Cleaning for libtool-1.3.5_2 ===> Cleaning for jpeg-6b_3 ===> Cleaning for tiff-3.6.1_1 ===> Cleaning for lcms-1.13,1 ===> Vulnerability check disabled ===> Extracting for lcms-1.13,1 Fix: Unkown, but I'll be happy to test possible approaches. How-To-Repeat: "portupgrade -a" works for me; I suspect that "portupgrade lcms-1.12,1" would be as effective.
State Changed From-To: open->feedback Sorry, can't reproduce. Do you set any compiler-flags in /etc/make.conf?
Responsible Changed From-To: freebsd-ports-bugs->vs Sorry, can't reproduce. Do you set any compiler-flags in /etc/make.conf?
I had been asked (apparently other than as a follow-up, since I don't see the exchange in the PR) about non-default compiler options in /etc/make.conf; I responded with the /etc/make.conf contents for each of 4 systems that exhibit the problem. As a further experiment, on my work desktop (2.4 GHz P4, UP), I moved /etc/make.conf aside, then tried "portupgrade lcms-1.12,1". Once again, the failure exhibits itself: frecnocpc2(4.10-S)[15] mv /etc/make.conf{,.save} && portupgrade lcms-1.12,1 ---> Upgrading 'lcms-1.12,1' to 'lcms-1.13,1' (graphics/lcms) ---> Building '/usr/ports/graphics/lcms' ===> Cleaning for libtool-1.3.5_2 ===> Cleaning for jpeg-6b_3 ===> Cleaning for tiff-3.6.1_1 ===> Cleaning for lcms-1.13,1 ===> Vulnerability check disabled ===> Extracting for lcms-1.13,1 >> Checksum OK for lcms-1.13.tar.gz. ===> Patching for lcms-1.13,1 ===> Applying FreeBSD patches for lcms-1.13,1 ===> lcms-1.13,1 depends on file: /usr/local/bin/libtool13 - found ===> lcms-1.13,1 depends on shared library: tiff.4 - found ===> Configuring for lcms-1.13,1 checking build system type... i386-portbld-freebsd4.10 checking host system type... i386-portbld-freebsd4.10 .... make testcms source='testcms.c' object='testcms.o' libtool=no depfile='.deps/testcms.Po' tmpdepfile='.deps/testcms.TPo' depmode=gcc /bin/sh ../depcomp cc -DPACKAGE_NAME=\"lcms\" -DPACKAGE_TARNAME=\"lcms\" -DPACKAGE_VERSION=\"1.13\" -DPACKAGE_STRING=\"lcms\ 1.13\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSIZEOF_INT=4 -DSIZEOF_UNSIGNED_INT=4 -DSIZEO F_LONG=4 -DSIZEOF_UNSIGNED_LONG=4 -DSIZEOF_LONG_LONG=8 -DSIZEOF_UNSIGNED_LONG_LONG=8 -DHasZLIB=1 -I. -I. -I../include -I../include -I/usr/local/include -O -pipe -c `test -f 'testcms.c' || echo './'`testcms.c /bin/sh ../libtool --mode=link cc -O -pipe -L/usr/local/lib -o testcms -L/usr/local/lib testcms.o ../src/liblcms.la mkdir .libs cc -O -pipe -L/usr/local/lib -o .libs/testcms -L/usr/local/lib testcms.o ../src/.libs/liblcms.so -lm -Wl,--rpath -Wl,/usr/local/lib creating testcms ./testcms little cms testbed. Ver 1.13 [build Jul 6 2004 09:49:07] Testing fixed point: 2.884667 = 2.884672 Testing fixed scaling...pass. Testing curves join ...pass. Testing reversing of curves ...Coarse error! 16 on entry 1021: FFD4/FFBE*** Error code 1 Stop in /common/ports/graphics/lcms/work/lcms-1.13/testbed. *** Error code 1 Stop in /common/ports/graphics/lcms. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade91463.0 make ** Fix the problem and try again. ** Listing the failed packages (*:skipped / !:failed) ! graphics/lcms (lcms-1.12,1) (unknown build error) ---> Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed frecnocpc2(4.10-S)[16] For reference, this system is: frecnocpc2(4.10-S)[16] uname -a FreeBSD frecnocpc2.noc.egation.com 4.10-STABLE FreeBSD 4.10-STABLE #19: Fri Jul 2 12:07:25 PDT 2004 root@frecnocpc2.noc.egation.com:/common/S1/obj/usr/src/sys/REPO i386 frecnocpc2(4.10-S)[17] At this point, I'd be interested in seeing any system that builds the port correctly.... Peace, david -- David H. Wolfskill david@catwhisker.org I do not "unsubscribe" from email "services" to which I have not explicitly subscribed. Rather, I block spammers' access to SMTP servers I control, and encourage others who are in a position to do so to do likewise.
It works fine here and on the cluster: little cms testbed. Ver 1.13 [build Jul 1 2004 04:20:04] Testing fixed point: 2.884667 = 2.884672 Testing fixed scaling...pass. Testing curves join ...pass. Testing reversing of curves ... dE: mean=0.00123875, SD=0.00346281, max=0.0622568 pass. http://pointyhat.freebsd.org/errorlogs/i386-4-latest-logs/lcms-1.13,1.log.bz2
>To: freebsd-gnats-submit@freebsd.org, david@catwhisker.org >Subject: Re: ports/68610: lcms upgrade from 1.12,1 -> 1.13,1 fails: "Coarse error! 16 on entry 1021" >From: "Volker Stolz" <vs@freebsd.org> >Date: Fri, 09 Jul 2004 11:00:46 +0200 >It works fine here and on the cluster: OK... so: what can I(/we) do to figure out what's going wrong with every system I try? At this point, I have no idea what a "coarse error" might be, let alone what would cause one to be detected; where would I get more clues (ideally, without turning this into a career unto itself)? Thanks, david -- David H. Wolfskill david@catwhisker.org I do not "unsubscribe" from email "services" to which I have not explicitly subscribed. Rather, I block spammers' access to SMTP servers I control, and encourage others who are in a position to do so to do likewise.
State Changed From-To: feedback->suspended Suspend and return to pool. I'm really out of wits here, sorry. I'm glad the package fixed it, though. Maybe you should contact the lcms-authors.
Responsible Changed From-To: vs->freebsd-ports-bugs Suspend and return to pool. I'm really out of wits here, sorry. I'm glad the package fixed it, though. Maybe you should contact the lcms-authors.
I just hit the same problem. As far as I can see, it looks like the problem is that testcms (the inbuilt test suite) gets its header files from the installed lcms rather than the one in its source directory, and the two are not compatible. Obviously this doesn't happen with a fresh install, but does happen when using portupgrade. A simple crude workaround is to pkg_delete -f <oldliblcms>, before building and installing the new one. - Mark
In gmane.os.freebsd.devel.ports.bugs, you wrote: > I just hit the same problem. As far as I can see, it looks like the > problem is that testcms (the inbuilt test suite) gets its header files > from the installed lcms rather than the one in its source directory, > and the two are not compatible. Obviously this doesn't happen with a > fresh install, but does happen when using portupgrade. Hm, looking at the compiler-invocation, I don't see any potential problem: (apart maybe from libtool not DTRT): make testcms source='testcms.c' object='testcms.o' libtool=no depfile='.deps/testcms.Po' tmpdepfile='.deps/testcms.TPo' depmode=gcc /bin/sh ../depcomp cc -DPACKAGE_NAME=\"lcms\" -DPACKAGE_TARNAME=\"lcms\" -DPACKAGE_VERSION=\"1.13\" -DPACKAGE_STRING=\"lcms\ 1.13\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSIZEOF_INT=4 -DSIZEOF_UNSIGNED_INT=4 -DSIZEO F_LONG=4 -DSIZEOF_UNSIGNED_LONG=4 -DSIZEOF_LONG_LONG=8 -DSIZEOF_UNSIGNED_LONG_LONG=8 -DHasZLIB=1 -I. -I. -I../include -I../include -I/usr/local/include -O -pipe -g -c `test -f 'testcms.c' || echo './'`testcms.c /bin/sh ../libtool --mode=link cc -O -pipe -g -L/usr/local/lib -o testcms -L/usr/local/lib testcms.o ../src/liblcms.la mkdir .libs cc -O -pipe -g -L/usr/local/lib -o .libs/testcms -L/usr/local/lib testcms.o ../src/.libs/liblcms.so -lm -Wl,--rpath -Wl,/usr/local/lib I'll see if I can reproduce this here. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME Two more month.
>Hm, looking at the compiler-invocation, I don't see any potential problem: >(apart maybe from libtool not DTRT): Unfortunately I didn't keep good enough notes as to exactly what happened. Here's what I do know: I was upgrading from 1.09 to 1.13, and hit this problem with testcms. Then I tried upgrading from 1.09 to 1.12, and still hit the problem, but fewer tests failed. So then I instrumented the library and test suite, and discovered that some of the internal tables were being initialized to all zeros instead of having the correct data. Usually this sort of thing only happens when an API has changed. So then I forced a pkg_delete on lcms (no other change), and rebuilt 1.13. The internal tests then all passed. So, I don't know for sure that this is a header file issue (that was my most likely hypothesis) or a linkage issue, but it is certainly a bad interaction between the test suite "testcms" and the previously installed library. Cheers, Mark
State Changed From-To: suspended->closed Today's version of the port links the liblcms into the testcms utility statically. This should fix the upgrade problems.