|
Home > Archive > Porting PostgreSQL > February 2006 > Failed install - libgen.so doesn't exist
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Failed install - libgen.so doesn't exist
|
|
| Poul Jensen 2006-01-30, 3:23 am |
| I don't think this is platform specific, but Fedora Core 2 it is anyway. I
was upgrading from v. 8.0 to 8.1.2. Ran the commands
../configure -with-perl
gmake
gmake check
with no apparent problems. Then
su root
gmake install
and it doesn't get far before this happens:
....
gmake -C timezone install
gmake[2]: Entering directory `/home/postgres/postgresql-8.1.2/src/timezone'
gmake -C ../../src/port all
gmake[3]: Entering directory `/home/postgres/postgresql-8.1.2/src/port'
gmake[3]: Nothing to be done for `all'.
gmake[3]: Leaving directory `/home/postgres/postgresql-8.1.2/src/port'
../zic -d /usr/local/pgsql/share/timezone ./data/africa ./data/antarctica
../data/asia ./data/australasia ./data/europe ./data/northamerica
../data/southamerica ./data/pacificnew ./data/etcetera ./data/factory
../data/backward ./data/systemv ./data/solar87 ./data/solar88 ./data/solar89
../zic: error while loading shared libraries: libgen.so: cannot open shared
object file: No such file or directory
gmake[2]: *** [install] Error 127
gmake[2]: Leaving directory `/home/postgres/postgresql-8.1.2/src/timezone'
....
No file called libgen.so exists on the server. Any suggestions?
Poul Jensen
| |
| Tom Lane 2006-01-30, 3:23 am |
| "Poul Jensen" <flyvholm@fys.ku.dk> writes:
> ./zic: error while loading shared libraries: libgen.so: cannot open shared
> object file: No such file or directory
Our configure script will pick up libgen if it exists, but it's a bit
hard to see how the configure script's test could succeed if there's no
such library anywhere on the machine. Did you look for libgen.a or
libgen.so.N ?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
| |
| Tom Lane 2006-01-30, 3:23 am |
| Poul Jensen <flyvholm@fys.ku.dk> writes:
> I've found that a folder containing a libgen.so file is mounted on the
> machine, but physically located on a different machine (which is why I
> didn't find it using 'locate'). The libgen.so file belongs to a software
> package for handling the radar data I'm working with. Other than that,
> there is a libgen.h file but no libgen.a or libgen.so.(anything).
Hm. Maybe we should remove the libgen item from configure. I have no
idea what platform it was required on (and there's no documentation
in the configure script about it) ... but it's very likely obsolete.
> Would you know what I need to fix to let the installation proceed?
I'd suggest make clean, edit src/Makefile.global to remove -lgen from
the LIBS macro, and rebuild.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
| |
| Bruce Momjian 2006-02-01, 11:24 am |
|
OK, so we should remove from configure.in?
AC_CHECK_LIB(gen, main)
---------------------------------------------------------------------------
Tom Lane wrote:
> Poul Jensen <flyvholm@fys.ku.dk> writes:
>
> Hm. Maybe we should remove the libgen item from configure. I have no
> idea what platform it was required on (and there's no documentation
> in the configure script about it) ... but it's very likely obsolete.
>
>
> I'd suggest make clean, edit src/Makefile.global to remove -lgen from
> the LIBS macro, and rebuild.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
| |
| Tom Lane 2006-02-01, 11:24 am |
| Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, so we should remove from configure.in?
> AC_CHECK_LIB(gen, main)
I'm just wondering how many of those AC_CHECK_LIB calls are needed only
on platforms that no one uses anymore ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
| |
| Bruce Momjian 2006-02-01, 11:24 am |
| Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>
>
> I'm just wondering how many of those AC_CHECK_LIB calls are needed only
> on platforms that no one uses anymore ...
I didn't want to mention that, but one big problem we have is that we
have no way to know what platforms are still using which configure and
pgport functions. It is very possible that 25% of what we have isn't
needed anymore, but we have no way of knowing which part.
We can start removing stuff and find out who complains in 8.2 but that
seems error-prone. My guess is that we are going to have to wait for
our useless percentage to reach 50% and then we comment out everything
and run it through the build farm until they all work, then run a
release with heavy beta testing.
However, at this stage, I don't think the cost/benefit is worth it.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
| |
| Tom Lane 2006-02-01, 11:24 am |
| Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
[color=darkred]
> I didn't want to mention that, but one big problem we have is that we
> have no way to know what platforms are still using which configure and
> pgport functions. It is very possible that 25% of what we have isn't
> needed anymore, but we have no way of knowing which part.
Agreed, but pgport functions that aren't actually selected for use don't
pose any hazards. AC_CHECK_LIB is an ongoing hazard for exactly the
reason the OP presents, namely that it will suck in any random library
it can find that happens to match by name. It's especially bad that
almost all of the tests are coded like
AC_CHECK_LIB(gen, main)
which means they don't even try to determine whether the library
is actually the one intended.
Now that we have the buildfarm I think that experimentation with this
sort of thing is a lot less risky than it used to be. I think we should
be working towards a project policy that AC_CHECK_LIB calls shalt not
use "main", but must name some symbol exported by the expected library.
If we can't find out what symbols the library is expected to provide,
it's time to dike it out.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
| |
| Bruce Momjian 2006-02-01, 11:24 am |
| Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>
>
> Agreed, but pgport functions that aren't actually selected for use don't
> pose any hazards. AC_CHECK_LIB is an ongoing hazard for exactly the
> reason the OP presents, namely that it will suck in any random library
> it can find that happens to match by name. It's especially bad that
> almost all of the tests are coded like
> AC_CHECK_LIB(gen, main)
> which means they don't even try to determine whether the library
> is actually the one intended.
>
> Now that we have the buildfarm I think that experimentation with this
> sort of thing is a lot less risky than it used to be. I think we should
> be working towards a project policy that AC_CHECK_LIB calls shalt not
> use "main", but must name some symbol exported by the expected library.
> If we can't find out what symbols the library is expected to provide,
> it's time to dike it out.
Agreed. Anyone want to do the legwork?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly
| |
| Tom Lane 2006-02-01, 11:24 am |
| Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
[color=darkred]
> Agreed. Anyone want to do the legwork?
It's not possible for any one person to do the legwork, but if several
people would look to see what the story is on their platforms, we would
have enough info to get started. We need to know which libraries
actually get sucked in and some plausible exported names to test for
each one.
I'll report on HPUX, Linux, and OSX later today, if no one beats me to
it.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
| |
| Bruce Momjian 2006-02-01, 11:24 am |
| Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>
>
> It's not possible for any one person to do the legwork, but if several
> people would look to see what the story is on their platforms, we would
> have enough info to get started. We need to know which libraries
> actually get sucked in and some plausible exported names to test for
> each one.
>
> I'll report on HPUX, Linux, and OSX later today, if no one beats me to
> it.
You want the Makefile.global LIBS line? On BSD/OS it is:
LIBS = -lintl -lssl -lcrypto -lz -lreadline -ltermcap -lgetopt \
-lcompat -lipc -ldl -lm -lutil
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
| |
| Bruce Momjian 2006-02-01, 11:24 am |
| Bruce Momjian wrote:
> Tom Lane wrote:
>
> You want the Makefile.global LIBS line? On BSD/OS it is:
>
> LIBS = -lintl -lssl -lcrypto -lz -lreadline -ltermcap -lgetopt \
> -lcompat -lipc -ldl -lm -lutil
Uh, can't we pull this line from all the buildfarm members and just
aggregate all the used libraries?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
| |
| Larry Rosenman 2006-02-01, 11:24 am |
| Bruce Momjian wrote:
> Bruce Momjian wrote:
>
> Uh, can't we pull this line from all the buildfarm members and just
> aggregate all the used libraries?
the issue is whether they actually export symbols that are NEEDED.
If someone can give me what to look for, I can cover the UnixWare case
(or give me a script
to run on 'firefly').
LER
--
Larry Rosenman
Database Support Engineer
PERVASIVE SOFTWARE. INC.
12365B RIATA TRACE PKWY
3015
AUSTIN TX 78727-6531
Tel: 512.231.6173
Fax: 512.231.6597
Email: Larry.Rosenman@pervasive.com
Web: www.pervasive.com
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
| |
| Bruce Momjian 2006-02-01, 11:24 am |
| Larry Rosenman wrote:
>
> the issue is whether they actually export symbols that are NEEDED.
Yea, ouch. This is going to be a pain.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly
| |
| Tom Lane 2006-02-01, 11:24 am |
| Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Larry Rosenman wrote:
[color=darkred]
> Yea, ouch. This is going to be a pain.
What I had in mind was to run "nm --ext --def" or local equivalent
on each library, and then pick out a few symbols that look plausible
to test for (or just send 'em all to the list if you are lazy). We
want to pick a symbol for each library that (a) is actually referenced
by Postgres and (b) exists in that library on all our platforms that
need that library.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
| |
| Rocco Altier 2006-02-02, 1:24 pm |
| Is there an easy way to tell what symbols are being used by Postgres?
For example, I was looking into libPW, and I want to see which symbols
might be used, but I don't see any being pulled into postgres binary or
the other commands.
BTW, from what I am reading is not thread-safe, so I wonder if we should
be including it even when we find it. Or what possible calls we might
be using from it.
-rocco
> -----Original Message-----
> From: pgsql-ports-owner@postgresql.org
> [mailto:pgsql-ports-owner@postgresql.org] On Behalf Of Tom Lane
> Sent: Wednesday, February 01, 2006 12:11 PM
> To: Bruce Momjian
> Cc: Larry Rosenman; flyvholm@fys.ku.dk; pgsql-ports@postgresql.org
> Subject: Re: [PORTS] Failed install - libgen.so doesn't exist
>
>
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>
>
> What I had in mind was to run "nm --ext --def" or local equivalent
> on each library, and then pick out a few symbols that look plausible
> to test for (or just send 'em all to the list if you are lazy). We
> want to pick a symbol for each library that (a) is actually referenced
> by Postgres and (b) exists in that library on all our platforms that
> need that library.
>
> regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
| |
| Poul Jensen 2006-02-04, 8:24 pm |
| Tom Lane wrote:
>"Poul Jensen" <flyvholm@fys.ku.dk> writes:
>
>
>
>Our configure script will pick up libgen if it exists, but it's a bit
>hard to see how the configure script's test could succeed if there's no
>such library anywhere on the machine. Did you look for libgen.a or
>libgen.so.N ?
>
> regards, tom lane
>
>
Thank you very much Tom.
I've found that a folder containing a libgen.so file is mounted on the
machine, but physically located on a different machine (which is why I
didn't find it using 'locate'). The libgen.so file belongs to a software
package for handling the radar data I'm working with. Other than that,
there is a libgen.h file but no libgen.a or libgen.so.(anything).
Would you know what I need to fix to let the installation proceed?
Thanks,
Poul Jensen
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly
| |
| Poul Jensen 2006-02-04, 8:24 pm |
|
>
>I'd suggest make clean, edit src/Makefile.global to remove -lgen from
>the LIBS macro, and rebuild.
>
> regards, tom lane
>
>
gmake clean + editing the makefile didn't quite do, but after deleting
the whole installation folder and the /usr/local/pgsql folder (I doubt
this was necessary, but went ahead since I had no data in there) I redid
the normal installation procedure with the one modification you pointed
me to: After running ./configure (but before gmake) I removed -lgen from
the LIBS macro in src/Makefile.global.
Installation completed. Thank you Tom!
Poul Jensen
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
|
|
|
|
|