Hello,

I try to get povray 3.7.0rc3 compiled successfully on a SUSE Linux Enterprise
Desktop 11 (x86_64). Boundary conditions:

- non-privileged user -> prefix.
- have to rely on a self-downloaded-and-extracted boost library version 1.46.1.
Its location is saved in the environment variable BOOST_ROOT.
- I took your advice to use --with-boost-thread=boost_thread-mt

Hence, this is my configure command:

../configure --prefix=/home/bioinfp/jang/apps/povray37
--with-boost-thread=boost_thread-mt COMPILED_BY="foo" CFLAGS="-I $BOOST_ROOT"
CXXFLAGS="-I $BOOST_ROOT"

The configure command above and 'make' ran successfully. I then invoked 'make
check', which did not return within an hour and still does not return.

The output of configure, make, make check so far:
http://gehrcke.de/files/perm/povray370rc3_conf_make_check.log

INSTALL says that this is a _short_ test. On the other hand, top lists one
povray process occupying one core with 100 % for more than an hour now :-) I
have eight of these: Intel(R) Xeon(R) CPU  X5450  @ 3.00GHz.

Is this situation correct so far? I have the feeling it is not..

Thanks,

Jan-Philip Gehrcke


--
http://gehrcke.de

Post a reply to this message

Do you have X11 running ?
("make check" expects to open a X window and render biscuit.pov... )

rendering of biscuit.pov is rather short, and you have to click on the
window to exit povray once rendered.

Can you interrupt ?(ctrl-c)
And retry ?

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> Do you have X11 running ?
> ("make check" expects to open a X window and render biscuit.pov... )
>
> rendering of biscuit.pov is rather short, and you have to click on the
> window to exit povray once rendered.
>
> Can you interrupt ?(ctrl-c)
> And retry ?

Quick response :-)

Oh.. yes, I am running X11 and there does not open up any window during 'make
check'. Ctrl+C and TERM did not work, I had to use SIGKILL (at first on 'make
check' and then on povray because it daemonized).

I now retried 'make check' and observed the same behavior. While povray hangs,
it does not show up in 'xlsclients' nor in 'netstat -nlp'

Any further suggestions? Is it a problem that povray does not find its
configuration file, as stated in the big log file in the opening post (it should
do well without, shouldn't it?)?



Thanks for your help,

Jan-Philip

Post a reply to this message

Le 21/06/2011 12:46, Jan-Philip Gehrcke a écrit :
> Le_Forgeron <lef### [at] freefr> wrote:
>> Do you have X11 running ?
>> ("make check" expects to open a X window and render biscuit.pov... )
>>
>> rendering of biscuit.pov is rather short, and you have to click on the
>> window to exit povray once rendered.
>>
>> Can you interrupt ?(ctrl-c)
>> And retry ?
> 
> Quick response :-)
> 
> Oh.. yes, I am running X11 and there does not open up any window during 'make
> check'. Ctrl+C and TERM did not work, I had to use SIGKILL (at first on 'make
> check' and then on povray because it daemonized).
> 
> I now retried 'make check' and observed the same behavior. While povray hangs,
> it does not show up in 'xlsclients' nor in 'netstat -nlp'
> 
> Any further suggestions? Is it a problem that povray does not find its
> configuration file, as stated in the big log file in the opening post (it should
> do well without, shouldn't it?)?
> 
> 

The missing configuration file is not an issue.

It should continue like:

> ./unix/povray +i./scenes/advanced/biscuit.pov -f +d +p +v +w320 +h240 +a0.3
+L./include
> povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is
discouraged.
> povray: cannot open the system configuration file
/home/grimbert/povray37/etc/povray/3.7/povray.conf: No such file or directory
> Persistence of Vision(tm) Ray Tracer Version 3.7.0.RC3 (g++ 4.4.3 @
>  x86_64-unknown-linux-gnu)
> This is a release candidate of POV-Ray version 3.7.0.
> General distribution is strongly discouraged.


Now, you are on a system which insist on putting 32 bits libraries in
/usr/lib despite it being a 64 bits system...

The 100% CPU is strange too. But I tested only with boost 1.40 installed
on system.

What does "ldd unix/povray" provides ?
(any missing or strange libraries ?)
Have you checked LD_LIBRARY_PATH environment variable ?

Mine is (ubuntu x86_64, working, but boost installed for all):
> $ ldd unix/povray
>         linux-vdso.so.1 =>  (0x00007fffe91f6000)
>         libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x00007fa12804e000)
>         libXpm.so.4 => /usr/lib/libXpm.so.4 (0x00007fa127e3d000)
>         libSM.so.6 => /usr/lib/libSM.so.6 (0x00007fa127c33000)
>         libICE.so.6 => /usr/lib/libICE.so.6 (0x00007fa127a18000)
>         libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fa1276e2000)
>         libIlmImf.so.6 => /usr/lib/libIlmImf.so.6 (0x00007fa127420000)
>         libz.so.1 => /lib/libz.so.1 (0x00007fa127209000)
>         libImath.so.6 => /usr/lib/libImath.so.6 (0x00007fa127003000)
>         libHalf.so.6 => /usr/lib/libHalf.so.6 (0x00007fa126dbf000)
>         libIex.so.6 => /usr/lib/libIex.so.6 (0x00007fa126ba0000)
>         libIlmThread.so.6 => /usr/lib/libIlmThread.so.6 (0x00007fa126999000)
>         libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00007fa126736000)
>         libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00007fa126512000)
>         libpng12.so.0 => /lib/libpng12.so.0 (0x00007fa1262eb000)
>         librt.so.1 => /lib/librt.so.1 (0x00007fa1260e2000)
>         libboost_thread.so.1.40.0 => /usr/lib/libboost_thread.so.1.40.0
(0x00007fa125ecc000)
>         libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fa125bb8000)
>         libm.so.6 => /lib/libm.so.6 (0x00007fa125934000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fa12571d000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0x00007fa125500000)
>         libc.so.6 => /lib/libc.so.6 (0x00007fa12517c000)
>         libasound.so.2 => /usr/lib/libasound.so.2 (0x00007fa124e9b000)
>         libdl.so.2 => /lib/libdl.so.2 (0x00007fa124c97000)
>         libdirectfb-1.2.so.0 => /usr/lib/libdirectfb-1.2.so.0 (0x00007fa124a13000)
>         libfusion-1.2.so.0 => /usr/lib/libfusion-1.2.so.0 (0x00007fa124809000)
>         libdirect-1.2.so.0 => /usr/lib/libdirect-1.2.so.0 (0x00007fa1245f0000)
>         libuuid.so.1 => /lib/libuuid.so.1 (0x00007fa1243ea000)
>         libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fa1241ce000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007fa128311000)
>         libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fa123fc9000)
>         libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fa123dc3000)

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> Le 21/06/2011 12:46, Jan-Philip Gehrcke a écrit :
> > Le_Forgeron <lef### [at] freefr> wrote:
> >> Do you have X11 running ?
> >> ("make check" expects to open a X window and render biscuit.pov... )
> >>
> >> rendering of biscuit.pov is rather short, and you have to click on the
> >> window to exit povray once rendered.
> >>
> >> Can you interrupt ?(ctrl-c)
> >> And retry ?
> >
> > Quick response :-)
> >
> > Oh.. yes, I am running X11 and there does not open up any window during 'make
> > check'. Ctrl+C and TERM did not work, I had to use SIGKILL (at first on 'make
> > check' and then on povray because it daemonized).
> >
> > I now retried 'make check' and observed the same behavior. While povray hangs,
> > it does not show up in 'xlsclients' nor in 'netstat -nlp'
> >
> > Any further suggestions? Is it a problem that povray does not find its
> > configuration file, as stated in the big log file in the opening post (it should
> > do well without, shouldn't it?)?
> >
> >
>
> The missing configuration file is not an issue.
>
> It should continue like:
>
> > ./unix/povray +i./scenes/advanced/biscuit.pov -f +d +p +v +w320 +h240 +a0.3
+L./include
> > povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is
discouraged.
> > povray: cannot open the system configuration file
/home/grimbert/povray37/etc/povray/3.7/povray.conf: No such file 
or directory
> > Persistence of Vision(tm) Ray Tracer Version 3.7.0.RC3 (g++ 4.4.3 @
> >  x86_64-unknown-linux-gnu)
> > This is a release candidate of POV-Ray version 3.7.0.
> > General distribution is strongly discouraged.
>
>
> Now, you are on a system which insist on putting 32 bits libraries in
> /usr/lib despite it being a 64 bits system...
>
> The 100% CPU is strange too. But I tested only with boost 1.40 installed
> on system.
>
> What does "ldd unix/povray" provides ?
> (any missing or strange libraries ?)
> Have you checked LD_LIBRARY_PATH environment variable ?

Yes, I've checked LD_LIBRARY_PATH and it is/was set to the directory where my
libboost_thread.so (1.46.1) is inside. Now, let's compare our ldd outputs.

differing versions (me):
libtiff.so.3 => /usr/lib64/libtiff.so.3 (0x00007f42aa14c000)
libboost_thread.so.1.36.0 => /usr/lib64/libboost_thread.so.1.36.0
(0x00007f42a98e5000)

differing versions(you):
libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00007fa126736000)
libboost_thread.so.1.40.0 => /usr/lib/libboost_thread.so.1.40.0
(0x00007fa125ecc000)

only in my config:
libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f42a89fb000)
libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007f42a87f3000)
libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007f42a85e9000)
libxcb-xlib.so.0 => /usr/lib64/libxcb-xlib.so.0 (0x00007f42a81e2000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f42a7fc6000)

only in your config:
libasound.so.2 => /usr/lib/libasound.so.2 (0x00007fa124e9b000)
libdirectfb-1.2.so.0 => /usr/lib/libdirectfb-1.2.so.0 (0x00007fa124a13000)
libfusion-1.2.so.0 => /usr/lib/libfusion-1.2.so.0 (0x00007fa124809000)
libdirect-1.2.so.0 => /usr/lib/libdirect-1.2.so.0 (0x00007fa1245f0000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fa1241ce000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fa123dc3000)

I've removed duplicates. Is there anything very suspicious in these differences
being responsible for my error?

The first insight for me is that my system insists on
using the libboost_thread.so.1.36.0 although libboost_thread.so and
libboost_thread.so.1.46.1 are in my LD_LIBRARY_PATH. I am wondering why
povray is specifically searching for the version 1.36.0? Was this fixed during
compile time (how does that make sense, configure says: checking for boostlib >=
1.37... yes?)?.

Anyway, I worked dirty around this problem by

ln -s /home/bioinfp/jang/apps/lib/libboost_thread.so.1.46.1
/home/bioinfp/jang/apps/lib/libboost_thread.so.1.36.0

Then ldd finds this link:

libboost_thread.so.1.36.0 =>
/home/bioinfp/jang/apps/lib/libboost_thread.so.1.36.0 (0x00007fcc628bc000)

and by following this link actually uses libboost_thread.so.1.41.1.

But still the same misbehavior during make check as above. Can we now be sure
that this issue is not libboost_thread related?

Jan-Philip

Post a reply to this message

Le 21/06/2011 15:20, Jan-Philip Gehrcke a écrit :
> The first insight for me is that my system insists on
> using the libboost_thread.so.1.36.0 although libboost_thread.so and
> libboost_thread.so.1.46.1 are in my LD_LIBRARY_PATH. I am wondering why
> povray is specifically searching for the version 1.36.0? Was this fixed during
> compile time (how does that make sense, configure says: checking for boostlib >=
> 1.37... yes?)?.

Well, the linker stage only request libboost_thread.so, or I hope so.
(with the -l directive in the unix/Makefile)
It's the embedded loader inside povray binary which solves it as 1.36
(or maybe the linker ld itself).

Have you granted trust to the local boost library (running ldconfig
after update of /etc/ld.so.conf (or whatever)) ?
(well, you need superuser access to do that...)

I still wonder what is doing the binary.
Could you reconfigure with --enable-debug and when running "make check",
attach a debugger on the povray process ?
and then display the stack (on gdb/ddd: "where" )

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> Well, the linker stage only request libboost_thread.so, or I hope so.
> (with the -l directive in the unix/Makefile)
> It's the embedded loader inside povray binary which solves it as 1.36
> (or maybe the linker ld itself).
>
> Have you granted trust to the local boost library (running ldconfig
> after update of /etc/ld.so.conf (or whatever)) ?
> (well, you need superuser access to do that...)
Yeah, I'll bother our admin only if this will be really necessary -- so let's
see how far we get without him. At the moment we can be pretty sure that povray
uses my libboost_thread.so.1.46.1 (for the debug output below keep in mind that
my /home/bioinfp/jang/apps/lib/libboost_thread.so.1.36.0 still links to the
1.46.1 version)

> I still wonder what is doing the binary.
> Could you reconfigure with --enable-debug and when running "make check",
> attach a debugger on the povray process ?
> and then display the stack (on gdb/ddd: "where" )

(gdb) attach 4277
Attaching to process 4277
Reading symbols from
/home/bioinfp/jang/sumpf/povray-3.7.0.RC3/unix/povray...done.
Reading symbols from /usr/lib64/libSDL-1.2.so.0...done.
Loaded symbols for /usr/lib64/libSDL-1.2.so.0
Reading symbols from /lib64/libpthread.so.0...done.
[Thread debugging using libthread_db enabled]
[New Thread 0x2b98e31c7950 (LWP 4278)]
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /usr/lib64/libXpm.so.4...done.
Loaded symbols for /usr/lib64/libXpm.so.4
Reading symbols from /usr/lib64/libSM.so.6...done.
Loaded symbols for /usr/lib64/libSM.so.6
Reading symbols from /usr/lib64/libICE.so.6...done.
Loaded symbols for /usr/lib64/libICE.so.6
Reading symbols from /usr/lib64/libX11.so.6...done.
Loaded symbols for /usr/lib64/libX11.so.6
Reading symbols from /usr/lib64/libIlmImf.so.6...done.
Loaded symbols for /usr/lib64/libIlmImf.so.6
Reading symbols from /lib64/libz.so.1...done.
Loaded symbols for /lib64/libz.so.1
Reading symbols from /usr/lib64/libImath.so.6...done.
Loaded symbols for /usr/lib64/libImath.so.6
Reading symbols from /usr/lib64/libHalf.so.6...done.
Loaded symbols for /usr/lib64/libHalf.so.6
Reading symbols from /usr/lib64/libIex.so.6...done.
Loaded symbols for /usr/lib64/libIex.so.6
Reading symbols from /usr/lib64/libIlmThread.so.6...done.
Loaded symbols for /usr/lib64/libIlmThread.so.6
Reading symbols from /usr/lib64/libtiff.so.3...done.
Loaded symbols for /usr/lib64/libtiff.so.3
Reading symbols from /usr/lib64/libjpeg.so.62...done.
Loaded symbols for /usr/lib64/libjpeg.so.62
Reading symbols from /usr/lib64/libpng12.so.0...done.
Loaded symbols for /usr/lib64/libpng12.so.0
Reading symbols from /lib64/librt.so.1...done.
Loaded symbols for /lib64/librt.so.1
Reading symbols from
/home/bioinfp/jang/apps/lib/libboost_thread.so.1.36.0...done.
Loaded symbols for /home/bioinfp/jang/apps/lib/libboost_thread.so.1.36.0
Reading symbols from /usr/lib64/libstdc++.so.6...done.
Loaded symbols for /usr/lib64/libstdc++.so.6
Reading symbols from /lib64/libm.so.6...done.
Loaded symbols for /lib64/libm.so.6
Reading symbols from /lib64/libgcc_s.so.1...done.
Loaded symbols for /lib64/libgcc_s.so.1
Reading symbols from /lib64/libc.so.6...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/libdl.so.2...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /usr/lib64/libXext.so.6...done.
Loaded symbols for /usr/lib64/libXext.so.6
Reading symbols from /usr/lib64/libXrandr.so.2...done.
Loaded symbols for /usr/lib64/libXrandr.so.2
Reading symbols from /usr/lib64/libXrender.so.1...done.
Loaded symbols for /usr/lib64/libXrender.so.1
Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libuuid.so.1...done.
Loaded symbols for /lib64/libuuid.so.1
Reading symbols from /usr/lib64/libxcb-xlib.so.0...done.
Loaded symbols for /usr/lib64/libxcb-xlib.so.0
Reading symbols from /usr/lib64/libxcb.so.1...done.
Loaded symbols for /usr/lib64/libxcb.so.1
Reading symbols from /usr/lib64/libXau.so.6...done.
Loaded symbols for /usr/lib64/libXau.so.6
0x00002b98df0fb5fd in pthread_mutex_lock () from /lib64/libpthread.so.0
(gdb) where
#0  0x00002b98df0fb5fd in pthread_mutex_lock () from /lib64/libpthread.so.0
#1  0x00002b98dec492a2 in ?? () from /lib64/ld-linux-x86-64.so.2
#2  0x00002b98e151e552 in std::basic_istream<char, std::char_traits<char> >&
std::getline<char, std::char_traits<char>, std::allocator<char>
>(std::basic_istream<char, std::char_traits<char> >&, std::basic_string<char,
std::char_traits<char>, std::allocator<char> >&, char) () from
/usr/lib64/libstdc++.so.6
#3  0x0000000000430bd0 in vfePlatform::UnixOptionsProcessor::parse_conf_file (
    this=0x92f7b0, Stream=@0x7fffb8f87850, conf_name=@0x92f7d8, user_mode=true)
    at unix/unixoptions.cpp:817
#4  0x0000000000431fe7 in vfePlatform::UnixOptionsProcessor::process_povray_conf
(this=0x92f7b0) at unix/unixoptions.cpp:1052
#5  0x0000000000432768 in UnixOptionsProcessor (this=0x92f7b0,
    session=<value optimized out>) at unix/unixoptions.cpp:195
#6  0x000000000042b000 in vfeUnixSession (this=0x92f2a0,
    id=<value optimized out>) at unix/vfeplatform.cpp:133
#7  0x000000000043e141 in main (argc=10, argv=0x7fffb8f881e8)
    at unix/unixconsole.cpp:452
(gdb)

Post a reply to this message

Le 21/06/2011 17:30, Jan-Philip Gehrcke nous fit lire :
> [Thread debugging using libthread_db enabled]
> [New Thread 0x2b98e31c7950 (LWP 4278)]

It can be interesting to look also at that thread too, as it might have
the mutex the main thread is expecting.

gdb command would be "info threads"
then "thread <number_of_the_thread_for_gdb>"
and "where" once there.

> 0x00002b98df0fb5fd in pthread_mutex_lock () from /lib64/libpthread.so.0
> (gdb) where
> #0  0x00002b98df0fb5fd in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1  0x00002b98dec492a2 in ?? () from /lib64/ld-linux-x86-64.so.2
> #2  0x00002b98e151e552 in std::basic_istream<char, std::char_traits<char> >&
> std::getline<char, std::char_traits<char>, std::allocator<char>
>> >(std::basic_istream<char, std::char_traits<char> >&, std::basic_string<char,
> std::char_traits<char>, std::allocator<char> >&, char) () from
> /usr/lib64/libstdc++.so.6
> #3  0x0000000000430bd0 in vfePlatform::UnixOptionsProcessor::parse_conf_file (
>     this=0x92f7b0, Stream=@0x7fffb8f87850, conf_name=@0x92f7d8, user_mode=true)
>     at unix/unixoptions.cpp:817
> #4  0x0000000000431fe7 in vfePlatform::UnixOptionsProcessor::process_povray_conf
> (this=0x92f7b0) at unix/unixoptions.cpp:1052
> #5  0x0000000000432768 in UnixOptionsProcessor (this=0x92f7b0,
>     session=<value optimized out>) at unix/unixoptions.cpp:195
> #6  0x000000000042b000 in vfeUnixSession (this=0x92f2a0,
>     id=<value optimized out>) at unix/vfeplatform.cpp:133
> #7  0x000000000043e141 in main (argc=10, argv=0x7fffb8f881e8)
>     at unix/unixconsole.cpp:452
> (gdb)

It could be interesting to up to #3 to get more information about Stream
(and line_number of unixoptions.cpp... parse_conf_file() )

For the time-being, it looks like a mutex-lock for that thread, done by
the system itself.

Are you somehow on a NFS mounted filesysem ? (like "your home is mounted
everywhere, whatever the system you log in" ?)

I'm used to --disable-io-restrictions for configure, you might give it a
try (at least for the experiment).

I wonder a bit about the construct

		while ( !Stream.eof() )
		{
			// get and preprocess line
			std::getline(Stream, line);
			line = pre_process_conf_line(line);
			++line_number;

			// skip empty line
			if(line.length() == 0)
				continue;

If the last line is length 0, would the eof() be evaluated (again) ?

Post a reply to this message

Am 21.06.2011 20:36, schrieb Le_Forgeron:

> I wonder a bit about the construct
>
> 		while ( !Stream.eof() )
> 		{
> 			// get and preprocess line
> 			std::getline(Stream, line);
> 			line = pre_process_conf_line(line);
> 			++line_number;
>
> 			// skip empty line
> 			if(line.length() == 0)
> 				continue;
>
> If the last line is length 0, would the eof() be evaluated (again) ?

The C/C++ language construct

     while ( <CONDITION_1> )
     {
         <STATEMENTS_A>
         if ( <CONDITION_2> ) continue;
         <STATEMENTS_B>
     }

is fully equivalent to

     while ( <CONDITION_1> )
     {
         <STATEMENTS_A>
         if ( ! <CONDITION_2> )
         {
             <STATEMENTS_B>
         }
     }

Post a reply to this message

Le 21/06/2011 21:30, clipka a écrit :
> Am 21.06.2011 20:36, schrieb Le_Forgeron:
> 
>> I wonder a bit about the construct
>>
>>         while ( !Stream.eof() )
>>         {
>>             // get and preprocess line
>>             std::getline(Stream, line);
>>             line = pre_process_conf_line(line);
>>             ++line_number;
>>
>>             // skip empty line
>>             if(line.length() == 0)
>>                 continue;
>>
>> If the last line is length 0, would the eof() be evaluated (again) ?
> 
> The C/C++ language construct
> 
>     while ( <CONDITION_1> )
>     {
>         <STATEMENTS_A>
>         if ( <CONDITION_2> ) continue;
>         <STATEMENTS_B>
>     }
> 
> is fully equivalent to
> 
>     while ( <CONDITION_1> )
>     {
>         <STATEMENTS_A>
>         if ( ! <CONDITION_2> )
>         {
>             <STATEMENTS_B>
>         }
>     }

Ok, thanks for the check. So that (i.e. loop with continue not detecting
the end of file) was a red herring.

In the meantime, I compiled on a Red Hat Server 6.1 /x86_64, and it
works fine too (once I installed boost
 and add the infamous --with-boost-thread=boost_thread_mt to configure)
(It's boost 1.41)

Alas, I have no Suse available.

-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message