[GE users] GE 6.0 vs. Berkeley DB 4.2.52 vs. 64-bit Solaris 9

Joachim Gabler joga at sun.com
Wed Jul 21 10:46:03 BST 2004


    [ 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 Greg,

the file source/libs/spool/berkeleydb/README describes how to build the 
Berkeley DB on various platforms including solaris 64bit (you have to 
append CFLAGS="-xarch=v9" CPPFLAGS="-xarch=v9" LDFLAGS="-xarch=v9" to 
the configure call).

The file also contains a section about the use of the RPC server.

64bit berkeley_db_svc dumping core is a known issue and has been 
reported to Sleepycat.
AFAIK this will be fixed in the next Berkeley DB release.
In the meantime you have to build a (statically linked) 32 bit 
berkeley_db_svc and copy it to your 64 bit berkeley db installation.

   Joachim

Greg Earle wrote:

> Hi,
>
> I'm new to Grid Engine and the list.  Please be gentle  :-)
>
> I plunged in and built the latest GE 6.0 release on a Solaris 9 machine.
>
> I noticed that by default, it wants to build everything in 64-bit.
> My build cruised along until it hit the part where it's supposed to
> interface with Berkeley DB 4.2.52, when it complained that my BDB
> bits were 32-bit, and everything else was 64-bit.
>
> So, I then tried to build Berkeley DB 4.2.52 as a pure 64-bit version.
> I thought "-xarch=v9a" in CFLAGS/CXXFLAGS/LDFLAGS would surely do
> the trick, but that wasn't sufficient.  Problems with "libtool" saw
> to that.
>
> I ended up getting some 64-bit patches from Sleepycat for 4.2.52
> (this is where I started wondering if I was the only person in the
> world that had ever run into this) and with those, I was able to do a
> successful build & install.
>
> I initialized my qmaster host to use Berkeley DB for the spooling
> and set up the RPC server, and tried to fire up the init.d script.
>
> It died at the launching of "berkeley_db_svc".
>
> Now I realize this is out of the realm of GE specifically; it also dies
> when run from "/usr/local/BerkeleyDB.4.2/bin/sparcv9/berkeley_db_svc"
> as well.  Bear with me a sec ...
>
> To make a long story short, there's a section in the Berkeley DB file
> (rpc_server/c/db_server_svc.c) that handles the registering of the DB
> service with "portmap" by doing an "svctcp_create(RPC_ANYSOCK, 0, 0)"
> followed by a "svc_register()".  To be exact:
>
>         (void) pmap_unset(DB_RPC_SERVERPROG, DB_RPC_SERVERVERS);
>
>         transp = (SVCXPRT *)svctcp_create(RPC_ANYSOCK, 0, 0);
>         if (transp == NULL) {
>                 fprintf(stderr, "cannot create tcp service.");
>                 exit(1);
>         }
>         if (!svc_register(transp, DB_RPC_SERVERPROG, 
> DB_RPC_SERVERVERS, db_rpc_serverprog_4002, IPPROTO_TCP)) {
>                 fprintf(stderr, "unable to register 
> (DB_RPC_SERVERPROG, DB_RPC_SERVERVERS, tcp).");
>                 exit(1);
>         }
>
> What's happening to me is that svctcp_create() is returning a
> non-NULL value into "transp", but it's not a valid one - it's
> returning something like "0x4a300", which can't be accessed (the
> binary is a fully 64-bit binary and its memory map starts at
> 0x100000000).  This inaccessible address gets passed in to the
> subsequent "svc_register()", and kablooie - SIGSEGV.  (I've just
> reported this behavior to Sleepycat.)
>
> I was going to report to Sun that their /usr/lib/sparcv9/libnsl.so.1
> 64-bit library has a bogus "svctcp_create()" implementation - but a
> degenerate test case that I later made up (a small wrapper around the
> above-quoted code, basically) actually works!  The value returned into
> "transp" in the test case is 0x100101c90, not 0x4a300.  Very bizarre!
> I have no idea why the same exact code would return two drastically
> different results.  (libnsl.so.1 is patched up to the latest patchlevel
> release, 113319-18.)
>
> Anyway, I'm posting this in the hopes that someone at Sun sees it, for
> one; and for another, I'm wondering if perhaps some earlier Grid Engine
> developer ran into this as well - I'll note wryly that the "64-bit"
> binaries for Solaris 7/8/9 (in "sge-6.0-bin-sol-sparc64.tar.gz")
> actually contain 32-bit binaries for the Berkeley DB stuff!  Check it:
>
> isolar:1:67 [/grid] # file utilbin/sol-sparc64/* | grep -v 64-bit
> utilbin/sol-sparc64/berkeley_db_svc:    ELF 32-bit MSB executable SPARC
> Version 1, dynamically linked, stripped
> utilbin/sol-sparc64/db_archive: ELF 32-bit MSB executable SPARC Version
> 1, dynamically linked, not stripped
> utilbin/sol-sparc64/db_checkpoint:      ELF 32-bit MSB executable SPARC
> Version 1, dynamically linked, not stripped
>
> Being 32-bit, of course the "berkeley_db_svc" binary in this binary
> distribution fires up just fine ...
>
> Am I the only person trying to run a 64-bit Berkeley DB 4.2.52
> with Grid Engine 6.0?  Is there even any need or point in doing so?
> Anyone?  Anyone?  Bueller?
>
>     - Greg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net
>

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Joachim Gabler          Tel: +49 941 3075-233 (x60233)
Sun Microsystems GmbH   Fax: +49 941 3075-222 (x60222)
Dr.-Leo-Ritter-Str. 7	mailto:joga at sun.com
D-93049 Regensburg      http://www.sun.de



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