| Redhat Linux 6.0 troubles continue [message #15629] |
Thu, 03 June 1999 00:00  |
Bruce L. Gotwols
Messages: 2
Registered: June 1999
|
Junior Member |
|
|
Hello all IDL Linux users,
On May 10th Jeremy Sanders posted a workaround which allows IDL to run
under the latest version of Linux available from Redhat (6.0). I found
this workaround to be very useful so I have included it below for any
latecomers. However, I have just discovered another failure mode. The
spawn command no longer works. This is very important if you want to
print anything from within IDL, as well as a myriad of other ways we use
spawn. To demonstrate the failure, all you have to do is spawn any unix
command, e.g..
spawn, 'ls'
The error messages that come back are:
tcsh: /usr/i386-glibc20-linux/lib/libcrypt.so.1: no version
information available (required by tcsh)
tcsh: /usr/i386-glibc20-linux/lib/libc.so.6: no version
information available (required by tcsh)
tcsh: error in loading shared libraries:
/usr/i386-glibc20-linux/lib/libc.so.6:
undefined symbol: _dl_global_scope_end
My interpretation of this failure mode is that the interactive shell I
am running (tcsh, but with identical failures under bash) is unhappy
with the old shared libraries that the workaround uses. So I'm damned if
I do and damned if I don't. Surprisingly, I find that call_external does
work.
Why so much interest in upgrading to redhat 6.0? The answer is that it
is the first major release that uses the new Linux 2.2 kernel. This
kernel, for the first time, routinely supports Symmetric Multi
Processing (SMP). SMP was available in earlier kernels as a patch, but
this is the first release where it comes into it's full glory from the
ground up. We at JHU/APL are deep into using multi processors as a way
of simultaneously doing data acquisition as well as Quick-Look analysis
in real time.
I purchased IDL for Linux about one month ago. I was not told until a
week after the purchase that it had not been recompiled since Redhat
version 5.1 which is on the order of one year ago! Nor would RSI give
me a schedule for the next recompile, saying only that they would
contact their Linux developer about the problem. So apparently they
don't even have this capability in-house. I am left wondering what is
the use of paying for an IDL maintenance contract, since RSI is
obviously doing virtually no maintenance, at least with the Linux
version.
I don't know if there are enough Linux users out there to bring enough
pressure to bear on RSI to clean up this problem. If there are, then I
propose we band together and collect a list of bugs which would be
submitted to RSI. That way, when they finally do get around to doing
something, perhaps they will fix some problems that might go unnoticed
until the next maintenance fix (which might be a year from now!). I will
volunteer to collect the bug reports, collate them into a readable
whole, and submit them to RSI as well as to this news group. I suggest
the deadline for submission be June 15th since after that you'll have
forgotten all about this message.
To start off the list here are several bugs and deficiencies that I am
aware of:
1. Recompile IDL under Redhat 6.0 (and any other vendors versions if
they are supported). This should fix the fatal bugs discussed below as
well as the bug introduced by the workaround discussed above.
2. Provide huge file support (> 2GB). This has been advertised as
being available under IDL 5.2 for about a year now, but it wasn't until
I tried to use it that I discovered it is not available on any Intel
based box (This means both Windows and Linux).
3. Fix systime() so it once again returns time with a precision greater
than one second. This affects the suite of time test programs such as
time_test2 such that they can only record integer number of seconds, and
therefore their results under Linux are inaccurate.
Cheers, Bruce Gotwols
On 10 May Jeremy Sanders gave a partial workaround:
> We managed to get IDL to work by installing the compatability > libraries. I then modified the idl script (the one which runs the > binary) at the end to read:
>
> app=$IDL_DIR/bin/bin.$OS$OSVER$ARCH/$APPLICATION
> if [ -e /lib/ld-2.0.7.so ] ; then
> exec $app $* $APP_ARGS
> else
> libdir=/usr/i386-glibc20-linux/lib
> export LD_LIBRARY_PATH="${libdir}:${LD_LIBRARY_PATH}" exec
> ${libdir}/ld-2.0.7.so $app $* $APP_ARGS
> fi
> This seems to work, although we haven't tried running programs with
> external shared libraries.
But on 19 May, G. Hugh Song described a continuing problem:
> I thought that all the compatibility problem has been solved by users. > In my case, one problem was solved following Jeremy's patch. But > when I lauched my application, I got:
> /usr/local/rsi/idl_5.2/bin/bin.linux/idl: error in loading shared > libraries
> /usr/X11R6/lib/libX11.so.6: undefined symbol: __bzero
> So, have you guys solved all the compatibility problem as much as you > want?
(The answer obviously is no, as described at the beginnig of this
message.)
----
Bruce L. Gotwols
Johns Hopkins University, Applied Physics Lab., Laurel MD 20723
Internet: gotwols@tesla.jhuapl.edu
Phone: 240-228-4543 FAX: 240-228-5548
Space Oceanography Group Home Page -- http://fermi.jhuapl.edu
|
|
|
|
| Re: Redhat Linux 6.0 troubles continue [message #15703 is a reply to message #15629] |
Fri, 04 June 1999 00:00  |
Jeremy Sanders
Messages: 4
Registered: May 1999
|
Junior Member |
|
|
Jeremy Sanders wrote:
> This isn't very good. I can't see any way around it. You can get around it a
> bit by replacing spawn,'x' by spawn,'/usr/i386-glibc20-linux/lib/ld-2.0.7.so
> x', but this isn't very satisfactory. Oh well, I'll have to think about
> it...
Oh, x has to be compiled using glibc20 for this to work. I suppose you could
get the files you need from RH5.2 for this.
Jeremy.
--
Jeremy Sanders jss@ast.cam.ac.uk Pembroke College, Cambridge. CB2 1RF
(01223) 337511 Institute of Astronomy, Madingley Road, Cambridge. CB3 0HA
- I could have gone for charm or beauty, but instead I went for strange -
|
|
|
|
| Re: Redhat Linux 6.0 troubles continue [message #15704 is a reply to message #15629] |
Fri, 04 June 1999 00:00 |
Jeremy Sanders
Messages: 4
Registered: May 1999
|
Junior Member |
|
|
"Bruce L. Gotwols" wrote:
>
> Hello all IDL Linux users,
> On May 10th Jeremy Sanders posted a workaround which allows IDL to run
> under the latest version of Linux available from Redhat (6.0). I found
> this workaround to be very useful so I have included it below for any
> latecomers. However, I have just discovered another failure mode. The
> spawn command no longer works. This is very important if you want to
> print anything from within IDL, as well as a myriad of other ways we use
> spawn.
This isn't very good. I can't see any way around it. You can get around it a
bit by replacing spawn,'x' by spawn,'/usr/i386-glibc20-linux/lib/ld-2.0.7.so
x', but this isn't very satisfactory. Oh well, I'll have to think about
it...
Jeremy.
--
Jeremy Sanders jss@ast.cam.ac.uk Pembroke College, Cambridge. CB2 1RF
(01223) 337511 Institute of Astronomy, Madingley Road, Cambridge. CB3 0HA
- I could have gone for charm or beauty, but instead I went for strange -
|
|
|
|
| Re: Redhat Linux 6.0 troubles continue [message #15715 is a reply to message #15629] |
Fri, 04 June 1999 00:00 |
Nigel Wade
Messages: 286
Registered: March 1998
|
Senior Member |
|
|
Bruce L. Gotwols wrote:
:>
:> Hello all IDL Linux users,
:> On May 10th Jeremy Sanders posted a workaround which allows
IDL to run
:> under the latest version of Linux available from Redhat (6.0). I
found
:> this workaround to be very useful so I have included it below for any
:> latecomers. However, I have just discovered another failure mode.
The
:> spawn command no longer works. This is very important if you want to
:> print anything from within IDL, as well as a myriad of other ways we
use
:> spawn. To demonstrate the failure, all you have to do is spawn any
unix
:> command, e.g..
:> spawn, 'ls'
:> The error messages that come back are:
:> tcsh: /usr/i386-glibc20-linux/lib/libcrypt.so.1: no version
:> information available (required by tcsh)
:>
:> tcsh: /usr/i386-glibc20-linux/lib/libc.so.6: no version
:> information available (required by tcsh)
:>
:> tcsh: error in loading shared libraries:
:> /usr/i386-glibc20-linux/lib/libc.so.6:
:> undefined symbol: _dl_global_scope_end
:>
:> My interpretation of this failure mode is that the interactive shell
I
:> am running (tcsh, but with identical failures under bash) is unhappy
:> with the old shared libraries that the workaround uses. So I'm damned
if
:> I do and damned if I don't. Surprisingly, I find that call_external
does
:> work.
:>
:> Why so much interest in upgrading to redhat 6.0? The answer is that
it
:> is the first major release that uses the new Linux 2.2 kernel. This
:> kernel, for the first time, routinely supports Symmetric Multi
:> Processing (SMP). SMP was available in earlier kernels as a patch,
but
:> this is the first release where it comes into it's full glory from
the
:> ground up. We at JHU/APL are deep into using multi processors as a
way
:> of simultaneously doing data acquisition as well as Quick-Look
analysis
:> in real time.
:>
> ----
> Bruce L. Gotwols
> Johns Hopkins University, Applied Physics Lab., Laurel MD 20723
Do you specifically require IDL 5.2?
I am running IDL 5.0 under RedHat 6.0 and it doesn't have this problem.
5.0 is so old that it was linked against libc5 so all you need to do is
install the libc5 runtime RPMs (or the libc5 development options if you
want
to use CALL_EXTERNAL or LINKIMAGE).
The real reason I am running 5.0 is that I haven't got around to
upgrading the
license for Linux yet. Given the problems you are reporting I don't
think I'll
bother ;)
--
-----------------------------------------------------------
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@ion.le.ac.uk
Phone : +44 (0)116 2523568, Fax : +44 (0)116 2523555
|
|
|
|
| Re: Redhat Linux 6.0 troubles continue [message #15725 is a reply to message #15629] |
Thu, 03 June 1999 00:00 |
Laurent Chardon
Messages: 8
Registered: June 1999
|
Junior Member |
|
|
Yes, as an SMP user of IDL for Linux, I am also very frustrated by IDL's
current state. Commands such as findfile() no longer work. Redhat 6.0 takes
care of numerous security issues in addition to the truly SMP kernel, so
there is no going back for us. Does this mean that we can no longer use IDL?
I hope that RSI is listening and that the answer is no. This kind of
problems really shouldn't happen, specially with what we pay for license
maintenance.
Thanks to everyone on this group for providing great support.
Laurent Chardon
PS: remove the NOT_THIS from my address if you want to reply directly.
Bruce L. Gotwols wrote in message <3756C35D.A4D93B7@tesla.jhuapl.edu>...
> Hello all IDL Linux users,
> On May 10th Jeremy Sanders posted a workaround which allows IDL to run
> under the latest version of Linux available from Redhat (6.0). I found
> this workaround to be very useful so I have included it below for any
> latecomers. However, I have just discovered another failure mode. The
> spawn command no longer works. This is very important if you want to
> print anything from within IDL, as well as a myriad of other ways we use
> spawn. To demonstrate the failure, all you have to do is spawn any unix
> command, e.g..
> spawn, 'ls'
> The error messages that come back are:
> tcsh: /usr/i386-glibc20-linux/lib/libcrypt.so.1: no version
> information available (required by tcsh)
>
> tcsh: /usr/i386-glibc20-linux/lib/libc.so.6: no version
> information available (required by tcsh)
>
> tcsh: error in loading shared libraries:
> /usr/i386-glibc20-linux/lib/libc.so.6:
> undefined symbol: _dl_global_scope_end
>
> My interpretation of this failure mode is that the interactive shell I
> am running (tcsh, but with identical failures under bash) is unhappy
> with the old shared libraries that the workaround uses. So I'm damned if
> I do and damned if I don't. Surprisingly, I find that call_external does
> work.
>
> Why so much interest in upgrading to redhat 6.0? The answer is that it
> is the first major release that uses the new Linux 2.2 kernel. This
> kernel, for the first time, routinely supports Symmetric Multi
> Processing (SMP). SMP was available in earlier kernels as a patch, but
> this is the first release where it comes into it's full glory from the
> ground up. We at JHU/APL are deep into using multi processors as a way
> of simultaneously doing data acquisition as well as Quick-Look analysis
> in real time.
>
> I purchased IDL for Linux about one month ago. I was not told until a
> week after the purchase that it had not been recompiled since Redhat
> version 5.1 which is on the order of one year ago! Nor would RSI give
> me a schedule for the next recompile, saying only that they would
> contact their Linux developer about the problem. So apparently they
> don't even have this capability in-house. I am left wondering what is
> the use of paying for an IDL maintenance contract, since RSI is
> obviously doing virtually no maintenance, at least with the Linux
> version.
>
> I don't know if there are enough Linux users out there to bring enough
> pressure to bear on RSI to clean up this problem. If there are, then I
> propose we band together and collect a list of bugs which would be
> submitted to RSI. That way, when they finally do get around to doing
> something, perhaps they will fix some problems that might go unnoticed
> until the next maintenance fix (which might be a year from now!). I will
> volunteer to collect the bug reports, collate them into a readable
> whole, and submit them to RSI as well as to this news group. I suggest
> the deadline for submission be June 15th since after that you'll have
> forgotten all about this message.
>
> To start off the list here are several bugs and deficiencies that I am
> aware of:
>
> 1. Recompile IDL under Redhat 6.0 (and any other vendors versions if
> they are supported). This should fix the fatal bugs discussed below as
> well as the bug introduced by the workaround discussed above.
>
> 2. Provide huge file support (> 2GB). This has been advertised as
> being available under IDL 5.2 for about a year now, but it wasn't until
> I tried to use it that I discovered it is not available on any Intel
> based box (This means both Windows and Linux).
>
> 3. Fix systime() so it once again returns time with a precision greater
> than one second. This affects the suite of time test programs such as
> time_test2 such that they can only record integer number of seconds, and
> therefore their results under Linux are inaccurate.
>
> Cheers, Bruce Gotwols
>
> On 10 May Jeremy Sanders gave a partial workaround:
>> We managed to get IDL to work by installing the compatability >
libraries. I then modified the idl script (the one which runs the >
binary) at the end to read:
>>
>> app=$IDL_DIR/bin/bin.$OS$OSVER$ARCH/$APPLICATION
>> if [ -e /lib/ld-2.0.7.so ] ; then
>> exec $app $* $APP_ARGS
>> else
>> libdir=/usr/i386-glibc20-linux/lib
>> export LD_LIBRARY_PATH="${libdir}:${LD_LIBRARY_PATH}" exec
>> ${libdir}/ld-2.0.7.so $app $* $APP_ARGS
>> fi
>
>> This seems to work, although we haven't tried running programs with
>> external shared libraries.
>
>
> But on 19 May, G. Hugh Song described a continuing problem:
>> I thought that all the compatibility problem has been solved by users. >
In my case, one problem was solved following Jeremy's patch. But > when
I lauched my application, I got:
>> /usr/local/rsi/idl_5.2/bin/bin.linux/idl: error in loading shared >
libraries
>> /usr/X11R6/lib/libX11.so.6: undefined symbol: __bzero
>
>> So, have you guys solved all the compatibility problem as much as you >
want?
> (The answer obviously is no, as described at the beginnig of this
> message.)
>
> ----
> Bruce L. Gotwols
> Johns Hopkins University, Applied Physics Lab., Laurel MD 20723
> Internet: gotwols@tesla.jhuapl.edu
> Phone: 240-228-4543 FAX: 240-228-5548
> Space Oceanography Group Home Page -- http://fermi.jhuapl.edu
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
