Failed install - libgen.so doesn't exist

"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

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

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

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

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

Tom Lane wrote:

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.

I took a first swing at this and rearranged some of these calls.

A couple of other findings:

nsl -- This might contain socket functions on some older platforms.

ipc, IPC, lc -- unknown

ld -- On AIX at least this seems to be some magic library but doesn't
have an obvious testable symbol.

compat -- could be anything, obviously

bsd, BSD -- I seem to recall that these and possibly compat are used by
Solaris to switch to BSD semantics on certain functions, but I don't
think we rely on that (anymore).

gen -- "generic" or "general", so this could be a lot, but it might
contain syslog on some platforms at least.

PW -- might be a compatibility library but none of the functions I found
are used by PostgreSQL.

resolv -- I don't think we need that.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Sat, Feb 04, 2006 at 01:54:52AM +0100, Peter Eisentraut wrote:

I took a first swing at this and rearranged some of these calls.

Cool. I actually went through a while ago trying to work out which
libraries were needed for which platforms. Comments below.

A couple of other findings:

nsl -- This might contain socket functions on some older platforms.

This appears to always be paired with -lsocket on solaris and svr4. In
theory -lsocket should pull in -lnsl automatically but maybe there are
linker issues.

ipc, IPC, lc -- unknown

-lipc was apparently for bsdi, nextstep. Don't know about the others.

ld -- On AIX at least this seems to be some magic library but doesn't
have an obvious testable symbol.

Indeed, appears to be AIX only.

compat -- could be anything, obviously

I have it listed as only needed for PRE_BSDI_2_1. I don't really know
though.

bsd, BSD -- I seem to recall that these and possibly compat are used by
Solaris to switch to BSD semantics on certain functions, but I don't
think we rely on that (anymore).

Apparently -lbsd is used on AIX but it contains pow() which is the
wrong one (the comment wasn't clear). -lBSD was for hpux. Linux used to
use it but not anymore.

gen -- "generic" or "general", so this could be a lot, but it might
contain syslog on some platforms at least.

No info on this one.

PW -- might be a compatibility library but none of the functions I found
are used by PostgreSQL.

Listed for old SCO. No idea what for though.

resolv -- I don't think we need that.

Probably included because some other library required it but didn't
include it in its link line, requiring every user of the library to do
it. The same way -ltermcap is required on a default -lreadline install.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Martijn van Oosterhout wrote:

compat -- could be anything, obviously

I have it listed as only needed for PRE_BSDI_2_1. I don't really know
though.

We can drop support for pre-2.1 BSDI.

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

kleptog@svana.org (Martijn van Oosterhout) writes:

On Sat, Feb 04, 2006 at 01:54:52AM +0100, Peter Eisentraut wrote:

I took a first swing at this and rearranged some of these calls.

ld -- On AIX at least this seems to be some magic library but doesn't
have an obvious testable symbol.

Indeed, appears to be AIX only.

Further, it appears to be AIX pre-4.3 only, when using it for dlopen()
replacement...

It would be an attractive idea to have configure detect not whether
it's open, but rather whether it is needed, and leave it out for AIX
4.3 and "better"...

Apparently -lbsd is used on AIX but it contains pow() which is the
wrong one (the comment wasn't clear). -lBSD was for hpux. Linux used to
use it but not anymore.

Seneca didn't notice it being picked up; it may be that it is only
detected and used on old versions of AIX...

PW -- might be a compatibility library but none of the functions I found
are used by PostgreSQL.

Listed for old SCO. No idea what for though.

Apparently this is for compatibility with the AT&T Programmers
Workbench toolkit; probably not too relevant to anyone these days...

On AIX, it gets detected, but functions are never used. I'll bet the
same is true on some other platforms (Solaris, HP/UX, and such).
--
"cbbrowne","@","acm.org"
http://cbbrowne.com/info/nonrdbms.html
Smith's Test for Artificial Life:
When animal-rights activists and right-to-life protesters are marching
outside your laboratory, then you know you've definitely made progress
in your artificial life research. -- Donald A. Smith

On Mon, Feb 06, 2006 at 04:45:11PM -0500, Chris Browne wrote:

Further, it appears to be AIX pre-4.3 only, when using it for dlopen()
replacement...

It would be an attractive idea to have configure detect not whether
it's open, but rather whether it is needed, and leave it out for AIX
4.3 and "better"...

That's kinda the point of these discussions, to answer the question:
what is in those libraries we need? Which symbol did we want? Rather
than trying to detect versions, is there some change in the library
(added or removed symbol) that we can base our decision on?

Does that library (ld) actually provide dlopen() or something else?

Thanks for the info.
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Martijn van Oosterhout wrote:

On Mon, Feb 06, 2006 at 04:45:11PM -0500, Chris Browne wrote:

Further, it appears to be AIX pre-4.3 only, when using it for dlopen()
replacement...

It would be an attractive idea to have configure detect not whether
it's open, but rather whether it is needed, and leave it out for AIX
4.3 and "better"...

That's kinda the point of these discussions, to answer the question:
what is in those libraries we need? Which symbol did we want? Rather
than trying to detect versions, is there some change in the library
(added or removed symbol) that we can base our decision on?

Does that library (ld) actually provide dlopen() or something else?

libld.a does not provide dlopen(), libdl.a does. libld.a provides
functions like ldopen() needed by src/backend/port/dynloader/aix.c for
the dl*() substitutes built on AIX versions that lack dlopen and
libdl.a, which appears to be versions prior to 4.3.

--
Seneca Cunningham
scunning@ca.afilias.info

The reason to check versions is that AIX added support for standard
dlopen at 4.3 and above, which means we don't need to use the port
routines built around the older library any more.

-rocco