SCIENTIFIC-LINUX-DEVEL Archives

April 2007

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Thu, 26 Apr 2007 11:02:00 -0700
Content-Type:
TEXT/PLAIN
Parts/Attachments:
TEXT/PLAIN (90 lines)
On Thu, 26 Apr 2007, Michel Jouvin wrote:

> They don't ignore anything, they don't have it for 64-bit and are expecting 
> their application to run in compatibility mode without any 64-bit stuff 
> provided with the app. For me this is a reasonable expectation.

They don't have it for 64-bit because the developers didn't build
the 64 bit packages where needed.  I don't understand either why
the 64 bit versions of those perl/python packages which include
shared-library files would not be built.

An example I'm thinking of is perl-Net-SSLeay - the 64-bit
version of this package is available from non-redhat sources, as is of
course the src.rpm file.  The glite-SE_dcache metapackage requires it,
but the gLite s/w distribution (external components) only includes
the 32-bit version of this package.  We needed the 64-bit version of
this package for dCache nodes here, as we do not and will not run
dCache nodes on 32-bit OS'es.

Perl and python RPMs are no longer platform independent when they include
and require shared library modules.

So I would be very interested in hearing from gLite people about which
perl/python packages could not be rebuilt for 64-bit arch. in the
non-external components of gLite.  It sounds to me like the problem is
being pushed to Scientific Linux, when it could be solved by building
the 64-bit packages..

  cheers,
   denice

> --On jeudi 26 avril 2007 09:54 -0500 "Marc W. Mengel" <[log in to unmask]> 
> wrote:
>
>> 
>> I think the issue that folks are concerned about is that they have a
>> package which is a combination of:
>>     platform-independant python/perl code
>>     binary loadable python/perl module (.so file)
>> which they cannot run on the 64-bit perl/python because they only have
>> a 32-bit .so file.
>> 
>> They seem to be ignoring the possiblity of shipping .so files for
>> all of the platforms they want to be able run on -- that is you could
>> have the ix86, the x86_64, and maybe sparc_solaris versions of the .so
>> with your package so that you could run it all three places...
>> 
>> Marc
>> 
>> Jaroslaw Polok wrote:
>>> Hi Michel
>>> 
>>> I still fail to understand what problem are you trying
>>> to solve here ....:
>>> 
>>> Either the application in question can be ported to
>>> 64 bit (so no problem ..) or not: then why to run it
>>> on an 64 bit system in first place ?
>>> 
>>> SL exists in both 32 and 64 bit variants ...
>>> 
>>> Cheers
>>> 
>>> Jarek
>>> 
>>> __
>>> -------------------------------------------------------
>>> _ Jaroslaw_Polok ___________________ CERN - IT/FIO/LA _
>>> _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _
>>> _____________________________________ +41_78_792_0795 _
>> 
>
>
>
>    *************************************************************
>    * Michel Jouvin                 Email : [log in to unmask] *
>    * LAL / CNRS                    Tel : +33 1 64468932        *
>    * B.P. 34                       Fax : +33 1 69079404        *
>    * 91898 Orsay Cedex                                         *
>    * France                                                    *
>    *************************************************************
>
>

-- 
deatrich @ triumf.ca, Science/Atlas         PH: +1 604-222-7665
<*> This moment's fortune cookie:
<apt> it has been said that redhat is the thing Marc Ewing wears on
       his head.

ATOM RSS1 RSS2