<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [PyKDE] ANNOUNCE: PyQt/PyKDE v0.11pre1</TITLE>
<META content="text/html; charset=windows-1252" http-equiv=Content-Type>
<META content="MSHTML 5.00.2314.1000" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>I installed PyKDE 0.11pre1 today, and didn't find 
any bugs so far. It's great stuff.</FONT></DIV>
<DIV><FONT face=Arial size=2>However, when working with auconf/automake i always 
have some trouble related to our non-standard installation.</FONT></DIV>
<DIV><FONT face=Arial size=2>I'm working for a bank, where we have a development 
environment, which is completely separate from the production 
environment.</FONT></DIV>
<DIV><FONT face=Arial size=2>We work solely with Solaris 2.6 (will move to 2.8 
one day). We have two separate installation paths, one for tools/programs used 
in production &amp; one for development only (so the guys in the trading room 
don't have access to compilers, header files, whatsoever). The production 
environment is being mirrored in development, to be able to test the software, 
if it will run in the trading room also. Additionally, we need to link out 
software against several commercial C++ libraries, which are useable only with 
specifc g++ versions. This has&nbsp;some implications:</FONT></DIV>
<DIV><FONT face=Arial size=2>1. We need to have several g++ versions installed. 
For the moment, we have one seperate path for each, but it would be better to be 
able to tell libtool or configure explicitly, which&nbsp;compiler to use. Not so 
easy, so far.</FONT></DIV>
<DIV><FONT face=Arial size=2>2. We MUST hardcode all shared library paths into 
the binaries (--rpath option), otherwise we can be 100 percent sure, that the 
programs won't run in our production environment (accessing the wrong libraries, 
or just not being able to find them).The libstdc++ is a special candidate, 
because libtool seldom includes it's path in the&nbsp;linking command line. 
Using LD_LIBRARY_PATH is no real option, because it's just not maintainable from 
the administration viewpoint (not for 350 users using different software 
packages). Using LD_RUN_PATH mostly works, so far, but not always - don't ask me 
why. For the moment, i always had to edit the libtool script to make it 
work.</FONT></DIV>
<DIV><FONT face=Arial size=2>Any ideas, how to make it "unpack, configure &amp; 
make install" ?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Thomas</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>