Thread: Failed install - libgen.so doesn't exist
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
"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
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
OK, so we should remove from configure.in?
AC_CHECK_LIB(gen, main)
---------------------------------------------------------------------------
Tom Lane wrote:
> 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 | 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
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
Tom Lane wrote: > 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 ... 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> 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.
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
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> 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. > > 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> 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?
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
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> 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?
>
> 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
Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > Tom Lane wrote: > > >> 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? > > > > 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 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
Bruce Momjian wrote: > Bruce Momjian wrote: >> Tom Lane wrote: >>> Bruce Momjian <pgman@candle.pha.pa.us> writes: >>>> Tom Lane wrote: >>>>> 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? >>> >>> 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 > > 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
Larry Rosenman wrote: > >>>> 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. > >> > >> 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? > > 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Larry Rosenman wrote:
>> the issue is whether they actually export symbols that are NEEDED.
> 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
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:
> > Larry Rosenman wrote:
> >> the issue is whether they actually export symbols that are NEEDED.
>
> > 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
>
Tom Lane wrote: >"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 > > 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
>>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 > > 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