Subject: pkg/29700: lang/sun-jre15 won't install using pkg_comp & libkver
To: None <,,>
From: None <kre@munnari.OZ.AU>
List: pkgsrc-bugs
Date: 03/15/2005 20:05:00
>Number:         29700
>Category:       pkg
>Synopsis:       lang/sun-jre15 won't install using pkg_comp & libkver
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 15 20:05:00 +0000 2005
>Originator:     Robert Elz
>Release:        NetBSD 2.0.1  (--pkgsrc current as of about a week ago)
	Prince of Songkla University
System: NetBSD 2.0.1 NetBSD 2.0.1 (DELTA-1.11-20050129) #1: Sat Jan 29 15:31:14 ICT 2005 i386
Architecture: i386
Machine: i386
	I build packages (on a -current system, not the 2.0.1 system that
	generated this PR) using pkg_comp & libkver (so I can install them
	on this system, and others).   Libkver is set for a 2.0 base
	system (if that matters).

	Something in the sun-jre15 (and I think, all the other sun-jXXNN
	packages, and perhaps other packages that run linux emulated
	binaries as part of the installation process) fails in its
	dynamic linking, as in ...

===> Verifying bin-install for ../../lang/sun-jre15
===> Binary install for sun-jre15-5.0.1nb2
Installing from source
=> Checksum SHA1 OK for jre-1_5_0_01-linux-i586.bin.
=> No RMD160 checksum recorded for jre-1_5_0_01-linux-i586.bin.
default -> /pkg_comp/obj/pkgsrc/lang/sun-jre15/default
===> Extracting for sun-jre15-5.0.1nb2
The following variables will affect the build process of this package,
sun-jre15-5.0.1nb2.  Their current value is shown below:

        * SUN_JRE15_USE_JCE = NO

You may want to abort the process now with CTRL-C and change their value
before continuing.  Be sure to run `/usr/bin/make clean' after
the changes.
===> Required installed package suse_compat-[0-9]*: suse_compat-9.1 found
===> Required installed package suse_x11-[0-9]*: suse_x11-9.1nb1 found
./install.sfx.15993: error while loading shared libraries: /usr/pkg/lib/ undefined symbol: _ctype_
cd: can't cd to jre1.5.0_01
/bin/mkdir -p /pkg_comp/obj/pkgsrc/lang/sun-jre15/default/jre1.5.0_01/.systemPrefs
/usr/bin/touch /pkg_comp/obj/pkgsrc/lang/sun-jre15/default/jre1.5.0_01/.systemPrefs/.system.lock
/usr/bin/touch /pkg_comp/obj/pkgsrc/lang/sun-jre15/default/jre1.5.0_01/.systemPrefs/.systemRootModFile
===> Patching for sun-jre15-5.0.1nb2
===> Overriding tools for sun-jre15-5.0.1nb2
===> Creating toolchain wrappers for sun-jre15-5.0.1nb2
===> Configuring for sun-jre15-5.0.1nb2
cd /pkg_comp/obj/pkgsrc/lang/sun-jre15/default/jre1.5.0_01/lib; for file in fontconfig.RedHat.2.1.bfc fontconfig.RedHat.3.bfc fontconfig.RedHat.8.0.bfc fontconfig.RedHat.bfc fontconfig.SuSE.bfc fontconfig.Sun.2003.bfc fontconfig.Sun.bfc fontconfig.Turbo.8.0.bfc fontconfig.Turbo.bfc fontconfig.bfc i386/jvm.cfg images/cursors/ javaws/ javaws/ javaws/ javaws/ javaws/ javaws/ javaws/ javaws/ javaws/messages_sv.propert!
 ies javaws/ javaws/ management/ security/; do                      /bin/mv -f $file $file.default;                done
cd: can't cd to /pkg_comp/obj/pkgsrc/lang/sun-jre15/default/jre1.5.0_01/lib
mv: rename to No such file or directory
mv: rename to No such file or directory

Followed by lots more rename failuers, all of which are because none of
the files exist to be reamed, which is most likely (I assume) because
of the

	./install.sfx.15993: error while loading shared libraries: /usr/pkg/lib/ undefined symbol: _ctype_
	cd: can't cd to jre1.5.0_01

And in particular, that undefined symbol.   Why _ctype_ would be
undefined is anyone's guess...

	Use pkg_comp and libkver to emulate a (slightly) older NetBSD
	system, and attempt to install lang/sun-jre15 (or I think,
	any one of several other packages).
	Beats me - find a definition of _ctype_ for libkver to link
	against, or stop libkver from needing it, or ...  (This isn't
	actually much of a critical symbol - as in, it wouldn't matter
	if libkver had a private copy of the cyupe data for its won
	use, and other functions used the "normal" libc provided
	data - I am guessing here that the linux libraries handle
	the ctype macros using different hidden symbols than NetBSD's do).

	Alternatively, make (somehow) a linux compiled version of for linux emulated binaries to use...

	I'm guessing!