Skip site navigation (1) Skip section navigation (2)

Re: ERROR: could not load library "...": Exec format error

From: Korry Douglas <korry(dot)douglas(at)enterprisedb(dot)com>
To: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: ERROR: could not load library "...": Exec format error
Date: 2010-02-09 14:37:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
> I have the $SUBJECT problem loading my own
> module in PostgreSQL. The server is HP-UX/ia64,
> PostgeSQL 8.4.2 was compiled with HP CC.
> pl/PgSQL can be loaded fine.
> ...:/usr/local/pgsql/pgsql-cc-8.4/lib# ldd
> => /usr/local/pgsql/runtime/lib/
> =>      /usr/lib/hpux64/
> =>    /usr/lib/hpux64/
> =>   /usr/lib/hpux64/
> "/usr/local/pgsql/runtime" is a link to "/usr/local/pgsql/pgsql- 
> cc-8.4"
> ...:/usr/local/pgsql/pgsql-cc-8.4/lib# file
>     ELF-64 shared object file - IA64
>    ELF-64 shared object file - IA64
> The module compilation was done using "USE_PGXS=1 gmake".
> How can I solve this issue?

IIRC, HP/UX doesn't like to dynamic-load shared libraries that use  
thread-local storage. Your shared library ( is linked  
against so you may be running into that problem.  I  
would recommend running the HP/UX equivalent of strace to capture more  
information about the call to dlopen()  (or perhaps shl_load(),  
depending on which version of HP/UX you are using).

			-- Korry

Korry Douglas
Senior Database Dude
EnterpriseDB Corporation
The Enterprise Postgres Company

Phone: (804)241-4301
Mobile: (620) EDB-NERD

In response to


pgsql-hackers by date

Next:From: Richard HuxtonDate: 2010-02-09 14:45:57
Subject: Re: Avoiding bad prepared-statement plans.
Previous:From: Magnus HaganderDate: 2010-02-09 14:36:55
Subject: Re: About psycopg2 (by its author)

pgsql-general by date

Next:From: Anton MaksimenkovDate: 2010-02-09 15:19:51
Subject: Re: Memory Usage and OpenBSD
Previous:From: Pavel StehuleDate: 2010-02-09 14:11:54
Subject: Re: string reverse fucntion?

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group