[GE users] To use SGE API for Perl/Python but for different arch

Mulley, Nikhil Nikhil.Mulley at deshaw.com
Sun Jan 27 23:33:29 GMT 2008


    [ The following text is in the "iso-8859-1" character set. ]
    [ Your display is set for the "ISO-8859-10" character set.  ]
    [ Some special characters may be displayed incorrectly. ]

Hi Andreas,

I got your suggestion, thanks. ... But the point, perhaps I was trying to make is how do I tell arch to say to let use sol-x86 binaries than sol-amd64 particularly when both are installed aside by?

$ ls /usr/local/sge/utilbin/ /usr/local/sge/bin/
/usr/local/sge/bin/:
sol-amd64  sol-x86

/usr/local/sge/utilbin/:
sol-amd64  sol-x86
$

$/usr/local/sge/util/arch
sol-amd64
$

When I implement the -s option(perhaps, more better switch letter could be suggested too), I can...

mulleyn at sx86beta1.nyc:/u/mulleyn>/usr/local/sge/util/arch -s
sol-x86

... And finally (badly), 

$ source /usr/local/sge/mycell/common/settings.csh 
$ /usr/local/sge/lib/sol-amd64

What do you suggest here? I can only think of having the '-s' option get into the arch script itself can solve things better.

>>is not to touch the arch script, but instead set
>>
>>    $SGE_ROOT/lib/sol-x86
>>
>>in LD_LIBRARY_PATH_32. 

I like to use LD_LIBRARY_PATH_32 and LD_LIBRARY_PATH_64 variables for compilation, but for the fact that many of the systems(both binary and the glue systems) outside/inside SGE and also many applications when binding to the DRMAA libraries at my place tend to use arch script a lot .... So, I was wondering if this option change could allow both(multiple) installations of different architectures for the similar workable platform, could add value.

Please let me know your consent.

Thanks,
Nikhil


-----Original Message-----
From: Andreas.Haas at Sun.COM [mailto:Andreas.Haas at Sun.COM] 
Sent: Friday, January 18, 2008 3:54 PM
To: users at gridengine.sunsource.net
Subject: RE: [GE users] To use SGE API for Perl/Python but for different arch

Hi Nikhil,

I understand you see a connection between the dynamic linking path of the DRMAA 
Perl binding, the LD_LIBRARY_PATH setting that results from the arch script and the
-l arch requests. Irrespective treating them separately is really necessary:

(1) Whether a DRMAA application such as your Perl binding needs 32-bit or 64-bit finally
depends on how the binding itself was built. If it was built as a 64-bit application

    $SGE_ROOT/lib/sol-amd64

is needed in LD_LIBRARY_PATH, if it was built as 32-bit application

    $SGE_ROOT/lib/sol-x86

must be set in LD_LIBRARY_PATH. That means the required LD_LIBRARY_PATH for your 
binding does not depend on isainfo -b or something related, but only the application.

(2) The LD_LIBRARY_PATH setting in the settings.{sh|csh} that is influenced by the arch 
script is done primarily to ensure that SGE binaries find reliably the dynamic libraries 
they need to function. For that reason I must really advise from changing the arch script 
and thus the settings.{sh|csh} LD_LIBRARY_PATH setting!

Note, actually this LD_LIBRARY_PATH dilemma was part of the reason for entirely abolishing 
the LD_LIBRARY_PATH setting by settings.{sh|csh} in 6.1

    http://gridengine.sunsource.net/issues/show_bug.cgi?id=2090

possibly a solution in your environment is not to touch the arch script, but instead set

    $SGE_ROOT/lib/sol-x86

in LD_LIBRARY_PATH_32. That way you tell the Solaris runtime linker where to search for 
32-bit libraries without affecting your SGE installation.

HTH,
Andreas


On Fri, 18 Jan 2008, Mulley, Nikhil wrote:

> Yes Andreas,
>
> I cannot even use sol-x86 even if I install the sol-x86 distro, because arch always results in sol-amd64 because of my system using 64-bit (result of isainfo -b).  While noting that both my perl and python in itself are 32-bit installations.
> I installed sol-x86 distro on my Solaris-10 system, besides the sol-amd64 installation.
> With the modifications to the arch script as below, and modifying the DRMAA both python's DRMAA and perl's Schedule::DRMAAc build files to invoke arch with -s option so that it could use and link with the sol-x86 libraries than sol-amd64 which would result in a wrong ELF class linking otherwise, I could get to install them working with the sol-x86.
>
> The situation is all my exec hosts are sol-amd64 hosts and the DRMAA bindings from these languages are 32-bit. It should not ideally matter what the architecture while submitting the job.
> The problem I am facing is that whenever using this libraries, the invocations of the jobs from these libraries, always use -l arch=sol-x86, while I do not have any of the execution hosts in the grid running the sol-x86 libraries and apparently the jobs fail simply attributing to the same arch resource_list value.
> So, I am wondering if I could set the resource list '-l arch=sol-x86', while submitting the job from the scripts, whether I would be able to get the jobs launched and executed. If yes, how? Can you please elicit some examples?
>
> Regards,
> Nikhil
>
>
> -----Original Message-----
> From: Andreas.Haas at Sun.COM [mailto:Andreas.Haas at Sun.COM]
> Sent: Thursday, January 17, 2008 2:44 PM
> To: users at gridengine.sunsource.net
> Subject: Re: [GE users] To use SGE API for Perl/Python but for different arch
>
> Hi Nikhil,
>
> have you tried to use the DRMAA library from the sol-x86 binary
> package? It is 32 bit and should work.
>
> Regards,
> Andreas
>
> On Thu, 17 Jan 2008, Mulley, Nikhil wrote:
>
>> Hi,
>>
>> I am using SGE-v6.0.11 on Solaris-10 with sol-amd64 binaries and perl is
>> built with 32bit. So, when I get to want to compile/use modules like
>> DRMAAc from cpan.org, they all turn out to be failures because of
>> incompatible ELFCLASS in the libraries (cc is also 32-bit). So I
>> wondered how could I make perl modules DRMAAc compiled for the
>> incompatible SGE arch sol-amd64.
>> I could not go for the alternative of recompiling perl with 64-bit
>> support all over again, but have an also installation of SGE sol-x86
>> also installed aside by sol-amd64 residence.
>>
>> I figured out that this architecture is much of reference from
>> $SGE_ROOT/util/arch. All the time arch ends up reporting sol-amd64
>> because of 'isainfo -b' returns to be '64'. I thought I could alleviate
>> this to some extent without changing the current behaviour and
>> infrastructure, if arch could somehow report the 32-bit locations if an
>> option is provided, which I could later make the tweaks of arch usage in
>> the Makefiles of Schedule::DRMAAc build and get it compiled against the
>> 32-bit installation.
>>
>> So, I ended up with this tweak to $SGE_ROOT/util/arch; and after
>> modifying Makefile.PL of the Schedule::DRMAAc to use 'arch -s' , I was
>> successully able to build and install the module for my 32-bit perl.
>> (and Voila!, I could also make it compile for my 32-bit python
>> installation after tweaking the setup.py ofcourse)
>>
>> Please let me know if this could be filed as an RFE and can make it to
>> the official release?
>>
>> Thanks,
>> Nikhil
>>
>>
>> But, the question still stands as, can I use the Schedule::DRMAAc perl
>> modules to run on my machine with 32-bit perl....
>>
>> --- /usr/local/sge/util/arch    2007-06-26 13:23:37.000000000 +0530
>> +++ ./arch      2008-01-17 03:05:51.294532000 +0530
>> @@ -38,6 +38,7 @@
>> #  PVM 3.x distribution, 22 Jul 1991 Robert Manchek manchek at CS.UTK.EDU.
>> #
>> #  call:   arch       (print SGEEE architecture string)
>> +#          arch -s   (print SGEEE architecture string on/for a 32-bit
>> platform)
>> #          arch -m    (print default MANPATH of system)
>> #          arch -mt   (print either "man" or "catman")
>> #          arch -lib  (print name of variable to extend shared library
>> path)
>> @@ -249,7 +250,7 @@
>>       ARCH=sol-x86
>>       case $osrelease in
>>       5.[7891]*)
>> -         if [ `isainfo -b` = 64 ]; then
>> +         if [ `isainfo -b` = 64 -a "$1" != "-s" ]; then
>>             ARCH=sol-amd64
>>          else
>>             ARCH=sol-x86
>> @@ -259,7 +260,7 @@
>>    *)
>>       case $osrelease in
>>       5.[7891]*)
>> -         if [ `isainfo -b` = 64 ]; then
>> +         if [ `isainfo -b` = 64 -a "$1" != "-s" ]; then
>>             ARCH=sol-sparc64
>>          else
>>             ARCH=sol-sparc
>> @@ -308,7 +309,7 @@
>>    ;;
>> esac
>>
>> -if [ "$1" = "-m" -o "$1" = "-mt" -o "$1" = "-lib" ]; then
>> +if [ "$1" = "-m" -o "$1" = "-mt" -o "$1" = "-lib" -o "$1" = "-s" ];
>> then
>>    MANTYPE=man
>>    SHARED_LIBRARY_PATH="LD_LIBRARY_PATH"
>>    DEFAULTMANPATH=/usr/man
>> @@ -343,8 +344,11 @@
>>       ;;
>>    sol-*)
>>       DEFAULTMANPATH=/usr/share/man
>> -      # if bit-specific variable already set, use this variable!
>> -      SHARED_LIBRARY_PATH_BITS="LD_LIBRARY_PATH_`isainfo -b`"
>> +      SHARED_LIBRARY_PATH_BITS="LD_LIBRARY_PATH"
>> +      if [ "$1" != "-s" ] ; then
>> +          # if bit-specific variable already set, use this variable!
>> +          SHARED_LIBRARY_PATH_BITS="LD_LIBRARY_PATH_`isainfo -b`"
>> +      fi
>>       if eval [ x\$$SHARED_LIBRARY_PATH_BITS != x ]; then
>>              SHARED_LIBRARY_PATH=$SHARED_LIBRARY_PATH_BITS
>>       fi
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>> For additional commands, e-mail: users-help at gridengine.sunsource.net
>>
>>
>
> <°)))><
>
> http://gridengine.info/
>
> Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
> Amtsgericht Muenchen: HRB 161028
> Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
> Vorsitzender des Aufsichtsrates: Martin Haering
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net
>
>

http://gridengine.info/

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list