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

Andreas.Haas at Sun.COM Andreas.Haas at Sun.COM
Mon Jan 28 13:37:04 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 Nikhil,

On Mon, 28 Jan 2008, Mulley, Nikhil wrote:

> 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.

No caveat from my side as long as the output of 'arch' doesn't change when issued without a new option.

>>> 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.

I may be too restrained, but I see only little added value from an 'arch' enhancement. 
Main reason is that 'arch' is not an official SGE interface and exposing it as new 
interface anyhow were a regression compared to

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

but I guess if adding '-32' and '-64' override options to the 'arch' script were 
a help to you and others, I were glad to speak up for it as a contribution and 
finally do the review.

Regards,
Andreas

>
> 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
>
>

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



    [ Part 2: "Attached Text" ]

    [ 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. ]

---------------------------------------------------------------------
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