On Sun, May 28, 2006, Ralf S. Engelschall wrote:
>On Sat, May 27, 2006, Bill Campbell wrote:
>
>> While building packages on a SLES9-SP3 system, mostly Release 2.5
>> with some CURRENT thrown in for flavour, I found a conflict
>> between the perl-gtk in Release 2.5 and wx-2.6.3-20060524.src.rpm
>> from the current tree. perl-gtk requires glib2 with_threads=no
>> while wx requires with_threads=yes. No other package we have
>> installed that requires glib2 seems to care about its threads.
>>
...
>The perl-gtk version in 2.5 really requires with_threads=no in glib2 as
>it isn't able to deal with its threads support. In CURRENT the perl-gtk
>is a newer one which supports with_threads=no and with_threads=yes
>and hence the glib2 has with_threads=yes by default (as more packages
>require it). If you really want to mix 2.5 and CURRENT here you have to
>pick perl-gtk from CURRENT, too.
Thanks for the info Ralf.
I've found some other packages that have to be built from CURRENT as well
(the Release 2.5 ncurses does funny things on a 64 bit system).
I don't really want to mix 2.5 with CURRENT, but have to get something
working on the 64-bit architectures for our production machines (the 32-bit
versions have been working on a mostly 2.3 tree).
At this point I'm climbing the learning curve on the 64 bit builds on SuSE
Linux Enterprise 9 SP3. I think that the only things that are
necessary are:
1. Modify the %{l_prefix}/etc/rc.d/rc.openpkg run control script's
LD_LIBRARY_PATH setting to prepend /lib64 /usr/lib64 to the
/lib/usr/lib part and prepend %{l_prefix}/lib64 before the
%{l_prefix}/lib since gcc puts several of its libraries there.
2. I had to build gcc --with-shared to get the Berkeley database
routines to compile although this was something I did early in my
build process so this may not be absolutely required.
3. Modify %{l_ldflags} to generate -L%{l_prefix}/lib64 -L%{l_prefix}/lib
so that builds would get the gcc 64 bit libraries. The attached
patch to the rpmtool script handles this.
4. Have the bootstrap script put %{l_prefix}lib64 in the /etc/ld.so.conf
file before the %{l_prefix}/lib entry. The /etc/ld.so.conf is used
frequently in configure scripts generated by the libtool, automake,
autoconf packages to generate search paths.
I think this should bin the openpkg.spec %post processing, but I
haven't been able to figure out where it's doing this.
Bill
--
INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
Government spending? I don't know what it's all about. I don't know
any more about this thing than an economist does, and, God knows, he
doesn't know much.
-- Will Rogers
--- rpmtool.orig 2006-05-13 08:56:10.000000000 -0700
+++ rpmtool 2006-05-28 12:12:35.311848968 -0700
@@ -535,7 +535,8 @@
fi
done
if [ $std -eq 0 ]; then
- ldflags="-L${opt_p}/lib$ldflags"
+ ldflags="-L${opt_p}/lib $ldflags"
+ test -d ${opt_p}/lib64 && ldflags="-L${opt_p}/lib64 $ldflags"
fi
echo "x$ldflags" | sed -e 's;^x;;' -e 's;^ *;;'
;;
