Re: Compiling on FreeBSD 2.2.x? (-export-dynamic unavailable)

Hello again,

I hope my original posting made it to the list, and that this list is read
and in use. The search features on fts.postgresql.org seem to be out of
order/not yet implemented, and no archives are to be found.

Could one of the FreeBSD-based PostgreSQL developers possibly take a
moment to have a look at making it work on 2.2.8-STABLE?

There seems to be several small details that don't work 'out of the box' -
eg. my system is being picked up as elf-based...

Unfortunately I am not skilled enough in either C or make syntax to fix
these issues myself.

Hoping for a helping hand.

Best regards,
Are Bryne

On Wed, 23 Jan 2002, Are Bryne wrote:

> Hello,
>
> I am trying to compile PostgreSQL 7.1.3 on a FreeBSD-2.2.8-STABLE
> system (yes, it is old, will update soon hopefully).
>
> I run into the problem that the linker doesn't know about the
> -export-dynamic option.
>
> Is there any way around this? Can I possibly compile/make things work
> without this option?
>
> I am using the ports infrastructure of FreeBSD as a base, but it is of
> course adapted to -CURRENT and the latest 4.X-STABLE branches. Here is
> the error message I get:
>
> .
> .
> .
> gmake[4]: Leaving directory `/usr/ports/databases/postgresql7/work/postgresql-7.1.3/src/backend/utils'
> gcc295 -O -pipe -DUSE_SSL -Wall -Wmissing-prototypes -Wmissing-declarations -L/usr/local/lib -lssl -lcrypto -L/usr/local/lib -R/usr/local/lib -export-dynamic access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o -lssl -lcrypto -lz -lbind -lcrypt -lcompat -lm -lutil -lreadline -o postgres
> Undefined entry symbol `xport-dynamic'
> ld: Spurious undefined symbols: # undefined symbols 1, reported 0
> collect2: ld returned 1 exit status
> gmake[3]: *** [postgres] Error 1
> gmake[3]: Leaving directory
> `/usr/ports/databases/postgresql7/work/postgresql-7.1.3/src/backend'
> gmake[2]: *** [all] Error 2
> gmake[2]: Leaving directory
> `/usr/ports/databases/postgresql7/work/postgresql-7.1.3/src'
> .
> .
> .
>
> Thanks in advance for all and any help!
>
> Best regards,
> Are Bryne

--
Communiqué DA Office: +47 22 44 33 99
Postboks 9050 Grønland Mobile: +47 900 22 009
NO-0133 Oslo URL: http://www.communique.no

Are Bryne <are-pgsql-ports(at)communique(dot)no> writes:
> Could one of the FreeBSD-based PostgreSQL developers possibly take a
> moment to have a look at making it work on 2.2.8-STABLE?
> There seems to be several small details that don't work 'out of the box' -
> eg. my system is being picked up as elf-based...

I think you have a misconfigured compiler. AFAICT, the only way that
configure would think a freebsd2 system to be elf-based is if the
compiler predefines __ELF__. This theory is strengthened by the fact
that you're evidently not using the system-provided compiler.

regards, tom lane

Are Bryne writes:

> I hope my original posting made it to the list, and that this list is read
> and in use. The search features on fts.postgresql.org seem to be out of
> order/not yet implemented, and no archives are to be found.

archives.postgresql.org

> Could one of the FreeBSD-based PostgreSQL developers possibly take a
> moment to have a look at making it work on 2.2.8-STABLE?

I doubt anyone's still using that, so you're going to have to give a
little input.

> There seems to be several small details that don't work 'out of the box' -
> eg. my system is being picked up as elf-based...

Where and how, and why is that wrong? Well, so it's not ELF-based, but
what is it, and why does it matter? Give us something to work with.

--
Peter Eisentraut peter_e(at)gmx(dot)net

Hello Tom,

Thank you for your reply. Please see below.

On Fri, 25 Jan 2002, Tom Lane wrote:

> Are Bryne <are-pgsql-ports(at)communique(dot)no> writes:
> > Could one of the FreeBSD-based PostgreSQL developers possibly take a
> > moment to have a look at making it work on 2.2.8-STABLE?
> > There seems to be several small details that don't work 'out of the box' -
> > eg. my system is being picked up as elf-based...
>
> I think you have a misconfigured compiler. AFAICT, the only way that
> configure would think a freebsd2 system to be elf-based is if the
> compiler predefines __ELF__. This theory is strengthened by the fact
> that you're evidently not using the system-provided compiler.

in configure, line 2198, this happens:
# Assume system is ELF if it predefines __ELF__ as 1,
# otherwise believe host_os based default.
case $host_os in
freebsd1*|freebsd2*) elf=yes;;
esac

Since $host_os is being picked up as freebsd2.2.8, this makes elf default.
It would seem to me (unless elf=yes is needed for another reason) that it
should be setting elf=no instead in these cases.

However, when I try compiling with elf=no in configure, this happens:

gcc295 -O -pipe -DUSE_SSL -Wall -Wmissing-prototypes
-Wmissing-declarations -fpic -DPIC
-I../../../../src/interfaces/ecpg/include
-I../../../../src/interfaces/libpq -I../../../../src/include
-I/usr/local/include -c -o misc.o misc.c
ar cr libecpg.a `lorder execute.o typename.o descriptor.o data.o error.o
prepare.o memory.o connect.o misc.o | tsort`
tsort: cycle in data
tsort: prepare.o
tsort: misc.o
tsort: cycle in data
tsort: error.o
tsort: execute.o
tsort: connect.o
tsort: cycle in data
tsort: error.o
tsort: execute.o
tsort: descriptor.o
tsort: memory.o
tsort: cycle in data
tsort: execute.o
tsort: descriptor.o
tsort: error.o
tsort: cycle in data
tsort: execute.o
tsort: descriptor.o
tsort: data.o
ranlib libecpg.a
/usr/bin/ld -x -Bshareable -Bforcearchive execute.o typename.o
descriptor.o data.o error.o prepare.o memory.o connect.o misc.o
-L../../../../src/interfaces/libpq -lpq -o libecpg.so.3.2.0
ld: no shared -lssl.2.-1 available
gmake[5]: *** [libecpg.so.3.2.0] Error 1
gmake[5]: Leaving directory `/usr/ports/databases/postgresql7/work/postgresql-7.1.3/src/interfaces/ecpg/lib'
gmake[4]: *** [all] Error 2
gmake[4]: Leaving directory `/usr/ports/databases/postgresql7/work/postgresql-7.1.3/src/interfaces/ecpg'
gmake[3]: *** [all] Error 2
gmake[3]: Leaving directory `/usr/ports/databases/postgresql7/work/postgresql-7.1.3/src/interfaces'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/usr/ports/databases/postgresql7/work/postgresql-7.1.3/src'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/usr/ports/databases/postgresql7/work/postgresql-7.1.3'
gmake: *** [all] Error 2

Stop.
*** Error code 1

Stop.
*** Error code 1

Stop.

I've got the following (having installed openssl-0.9.6b):
-rw-r--r-- 1 root wheel 60614 Aug 2 22:49 /usr/local/include/openssl/ssl.h
-rw-r--r-- 1 root wheel 199168 Aug 2 22:49 /usr/local/lib/libssl.a
lrwxrwxrwx 1 root wheel 11 Aug 2 22:49 /usr/local/lib/libssl.so -> libssl.so.2
-r--r--r-- 1 bin bin 167936 Feb 13 2001 /usr/local/lib/libssl.so.1
-r--r--r-- 1 bin bin 163840 Aug 2 22:49 /usr/local/lib/libssl.so.2

I am attaching the config.status file generated by the last run-through.

> regards, tom lane

Thank you for your help. I appreciate it.

Regards,
Are Bryne
--
Communiqué DA Office: +47 22 44 33 99
Postboks 9050 Grønland Mobile: +47 900 22 009
NO-0133 Oslo URL: http://www.communique.no

Hi,

On Fri, 25 Jan 2002, Peter Eisentraut wrote:

> Are Bryne writes:
>
> > I hope my original posting made it to the list, and that this list is read
> > and in use. The search features on fts.postgresql.org seem to be out of
> > order/not yet implemented, and no archives are to be found.
>
> archives.postgresql.org

Thank you. Unfortunately, when trying
http://archives.postgresql.org/pgsql-ports/, I get the following message:
Fatal error: Failed opening required '/usr/local/www/archives/php_config.php'
(include_path='/usr/local/www/phplib:.') in /usr/local/www/archives/pgsql-ports/index.php on line 6

I've been in contact with Vince Vielhaber about pgsql-ports not being
linked to from the user's lounge (nor in fact developer's corner), and not
being on the list in the subscription form on the web. He acknowledged
this, and thought it strange it hadn't been noticed before. I am sure he
will realize that http://archives.postgresql.org/pgsql-ports/ is out of
order too.

> > There seems to be several small details that don't work 'out of the box' -
> > eg. my system is being picked up as elf-based...
>
> Where and how, and why is that wrong? Well, so it's not ELF-based, but
> what is it, and why does it matter? Give us something to work with.

Please see my reply to Tom Lane.

Thank your for your reply, btw.

Regards,
Are Bryne
--
Communiqué DA Office: +47 22 44 33 99
Postboks 9050 Grønland Mobile: +47 900 22 009
NO-0133 Oslo URL: http://www.communique.no

Are Bryne <are-pgsql-ports(at)communique(dot)no> writes:
> # Assume system is ELF if it predefines __ELF__ as 1,
> # otherwise believe host_os based default.
> case $host_os in
> freebsd1*|freebsd2*) elf=yes;;
> esac

> Since $host_os is being picked up as freebsd2.2.8, this makes elf default.

Argh, that's what I get for looking at current sources and not 7.1.3.
In current sources we have

# Assume system is ELF if it predefines __ELF__ as 1,
# otherwise believe host_os based default.
case $host_os in
freebsd1*|freebsd2*) elf=no;;
freebsd3*|freebsd4*) elf=yes;;
esac

so obviously somebody figured out that freebsd2 is not using elf.
Hacking configure as you did is the right answer for 7.1.

> /usr/bin/ld -x -Bshareable -Bforcearchive execute.o typename.o
> descriptor.o data.o error.o prepare.o memory.o connect.o misc.o
> -L../../../../src/interfaces/libpq -lpq -o libecpg.so.3.2.0
> ld: no shared -lssl.2.-1 available

I don't think we can help you here. Either deselect SSL support
or install a sharable OpenSSL library.

regards, tom lane

On Fri, 25 Jan 2002, Tom Lane wrote:

> Are Bryne <are-pgsql-ports(at)communique(dot)no> writes:
>
> so obviously somebody figured out that freebsd2 is not using elf.
> Hacking configure as you did is the right answer for 7.1.

Good.

> > /usr/bin/ld -x -Bshareable -Bforcearchive execute.o typename.o
> > descriptor.o data.o error.o prepare.o memory.o connect.o misc.o
> > -L../../../../src/interfaces/libpq -lpq -o libecpg.so.3.2.0
> > ld: no shared -lssl.2.-1 available
^
\___ This has nothing to do with it?

> I don't think we can help you here. Either deselect SSL support
> or install a sharable OpenSSL library.

file on the .so gives:
/usr/local/lib/libssl.so.2: FreeBSD/i386 compact demand paged shared library

> regards, tom lane

Thank you.

Regards,
Are Bryne
--
Communiqué DA Office: +47 22 44 33 99
Postboks 9050 Grønland Mobile: +47 900 22 009
NO-0133 Oslo URL: http://www.communique.no

Are Bryne <are-pgsql-ports(at)communique(dot)no> writes:
> ld: no shared -lssl.2.-1 available
> ^
> \___ This has nothing to do with it?

Hmm, I didn't look that closely.

> file on the .so gives:
> /usr/local/lib/libssl.so.2: FreeBSD/i386 compact demand paged shared library

Okay, so you do have a proper shared library.

Since the ecpg link command didn't mention ssl explicitly, I guess the
reference must be coming out of libpq.so. What do you get if you run
ldd on libpq.so? (I think it's called ldd on bsd, if not try chatr.)

regards, tom lane

On Fri, 25 Jan 2002, Tom Lane wrote:

> Okay, so you do have a proper shared library.
>
> Since the ecpg link command didn't mention ssl explicitly, I guess the
> reference must be coming out of libpq.so. What do you get if you run
> ldd on libpq.so? (I think it's called ldd on bsd, if not try chatr.)

Yes, it's ldd.
ldd: work/postgresql-7.1.3/src/interfaces/libpq/libpq.so: not a dynamic executable

(but, of course, it's a link :)
% ll work/postgresql-7.1.3/src/interfaces/libpq/libpq.so*
lrwxrwxrwx 1 are portsmas 12 Jan 25 21:16 work/postgresql-7.1.3/src/interfaces/libpq/libpq.so -> libpq.so.2.1
lrwxrwxrwx 1 are portsmas 12 Jan 25 21:16 work/postgresql-7.1.3/src/interfaces/libpq/libpq.so.2 -> libpq.so.2.1
-rwxr-xr-x 1 are portsmas 64849 Jan 25 21:16 work/postgresql-7.1.3/src/interfaces/libpq/libpq.so.2.1

and:
% ldd work/postgresql-7.1.3/src/interfaces/libpq/libpq.so.2.1
ldd: work/postgresql-7.1.3/src/interfaces/libpq/libpq.so.2.1: not a dynamic executable

% file work/postgresql-7.1.3/src/interfaces/libpq/libpq.so.2.1
work/postgresql-7.1.3/src/interfaces/libpq/libpq.so.2.1: FreeBSD/i386 compact demand paged shared library not stripped

So ldd doesn't work for libraries, only executables...

> regards, tom lane

Thanks.

Regards,
Are Bryne
--
Communiqué DA Office: +47 22 44 33 99
Postboks 9050 Grønland Mobile: +47 900 22 009
NO-0133 Oslo URL: http://www.communique.no

Are Bryne <are-pgsql-ports(at)communique(dot)no> writes:
> So ldd doesn't work for libraries, only executables...

Possibly it would work to explicitly include "-lssl" in the link
command for libecpg. In src/interfaces/ecpg/lib/Makefile,
add -lssl to the line "SHLIB_LINK= $(libpq)" and see if it's happier.

regards, tom lane

Are Bryne writes:

> However, when I try compiling with elf=no in configure, this happens:
>
> gcc295 -O -pipe -DUSE_SSL -Wall -Wmissing-prototypes
^^^^^^^^^

Where does this come from? This doesn't appear in the source code.

> ld: no shared -lssl.2.-1 available

I'd suggest trying to build without OpenSSL first. Then check out how
libpq is being linked. It seems it's somehow picking up a wrong libssl
reference, but I don't understand the non-elf formats enough to be able to
tell you how.

--
Peter Eisentraut peter_e(at)gmx(dot)net

On Fri, 25 Jan 2002, Tom Lane wrote:

> Are Bryne <are-pgsql-ports(at)communique(dot)no> writes:
> > So ldd doesn't work for libraries, only executables...
>
> Possibly it would work to explicitly include "-lssl" in the link
> command for libecpg. In src/interfaces/ecpg/lib/Makefile,
> add -lssl to the line "SHLIB_LINK= $(libpq)" and see if it's happier.

--- Makefile.orig Fri Jan 25 22:43:12 2002
+++ Makefile Fri Jan 25 22:44:30 2002
@@ -22,7 +22,7 @@
OBJS= execute.o typename.o descriptor.o data.o error.o prepare.o memory.o
\
connect.o misc.o

-SHLIB_LINK= $(libpq)
+SHLIB_LINK= $(libpq) -lssl

all: all-lib

I clean out *.o and *.a from src/interfaces/ecpg/lib/ and make gives:

gcc295 -O -pipe -DUSE_SSL -Wall -Wmissing-prototypes
-Wmissing-declarations -fpic -DPIC
-I../../../../src/interfaces/ecpg/include
-I../../../../src/interfaces/libpq -I../../../../src/include
-I/usr/local/include -c -o misc.o misc.c
ar cr libecpg.a `lorder execute.o typename.o descriptor.o data.o error.o
prepare.o memory.o connect.o misc.o | tsort`
tsort: cycle in data
tsort: prepare.o
tsort: misc.o
tsort: cycle in data
tsort: error.o
tsort: execute.o
tsort: connect.o
tsort: cycle in data
tsort: error.o
tsort: execute.o
tsort: descriptor.o
tsort: memory.o
tsort: cycle in data
tsort: execute.o
tsort: descriptor.o
tsort: error.o
tsort: cycle in data
tsort: execute.o
tsort: descriptor.o
tsort: error.o
tsort: cycle in data
tsort: execute.o
tsort: descriptor.o
tsort: data.o
ranlib libecpg.a
/usr/bin/ld -x -Bshareable -Bforcearchive execute.o typename.o
descriptor.o data.o error.o prepare.o memory.o connect.o misc.o
-L../../../../src/interfaces/libpq -lpq -lssl -o libecpg.so.3.2.0
ld: no shared -lssl.2.-1 available
gmake[5]: *** [libecpg.so.3.2.0] Error 1
gmake[5]: Leaving directory `/usr/ports/databases/postgresql7/work/postgresql-7.1.3/src/interfaces/ecpg/lib'

So the same error message... I don't understand where the -1 comes from,
though...

> regards, tom lane

Thanks,
Are Bryne
--
Communiqué DA Office: +47 22 44 33 99
Postboks 9050 Grønland Mobile: +47 900 22 009
NO-0133 Oslo URL: http://www.communique.no

Are Bryne <are-pgsql-ports(at)communique(dot)no> writes:
> So the same error message... I don't understand where the -1 comes from,
> though...

Me either. References from one shared library to another are messy on a
lot of Unixen, though, particularly older platforms. It may not work at
all, or it may require some weird switch to be given while building
libpq.so or libecpg.so.

I think what you need at this point are some FreeBSD gurus not Postgres
gurus. Though they may just tell you to update to a newer FreeBSD release.

In the meantime perhaps you can survive without ssl support ...

regards, tom lane

On Fri, 25 Jan 2002, Peter Eisentraut wrote:

> Are Bryne writes:
>
> > However, when I try compiling with elf=no in configure, this happens:
> >
> > gcc295 -O -pipe -DUSE_SSL -Wall -Wmissing-prototypes
> ^^^^^^^^^
>
> Where does this come from? This doesn't appear in the source code.

I'm trying to make use of the FreeBSD ports framework.

% pwd
/usr/ports/databases/postgresql7
% less Makefile.inc
# ODBC
WITH_ODBC=YES
CONFIGURE_ARGS+= --with-odbc

# SSL
USE_OPENSSL= yes
CFLAGS+= -DUSE_SSL
WITH_SSL= yes
CONFIGURE_ENV+= LDFLAGS="-L${OPENSSLLIB} -lssl -lcrypto"
CONFIGURE_ARGS+= --with-openssl

# Multibyte
CONFIGURE_ARGS+= --enable-multibyte=LATIN1

The config.status therefore shows (at the top):
# ./configure --enable-locale --enable-syslog --with-CXX
--sysconfdir=/usr/local/etc/postgresql '--with-includes=/usr/local/include '
--with-libraries=/usr/local/lib --docdir=/usr/local/share/doc
--includedir=/usr/local/include/pgsql --with-odbc --with-openssl
--enable-multibyte=LATIN1 --prefix=/usr/local i386--freebsd2.2.8

There might be more relevant information further down in the
config.status. I included it a few posts back (gzip'ed attachment - maybe
it wasn't necessary to compress it).

> > ld: no shared -lssl.2.-1 available
>
> I'd suggest trying to build without OpenSSL first. Then check out how
> libpq is being linked. It seems it's somehow picking up a wrong libssl
> reference, but I don't understand the non-elf formats enough to be able to
> tell you how.

OK. I'll try that.

Thanks.

Regards,
Are Bryne
--
Communiqué DA Office: +47 22 44 33 99
Postboks 9050 Grønland Mobile: +47 900 22 009
NO-0133 Oslo URL: http://www.communique.no

On Fri, 25 Jan 2002, Tom Lane wrote:

> I think what you need at this point are some FreeBSD gurus not Postgres
> gurus. Though they may just tell you to update to a newer FreeBSD release.

I'm fearing the worst. :-)

I understand that a lot (?) of the PostgreSQL developers are FreeBSD users
- might there therefore be a few names (adresses) you could mention that I
could run this by?

> In the meantime perhaps you can survive without ssl support ...

I'll try.

> regards, tom lane

Thank you very much for your help so far.

Best regards,
Are Bryne
--
Communiqué DA Office: +47 22 44 33 99
Postboks 9050 Grønland Mobile: +47 900 22 009
NO-0133 Oslo URL: http://www.communique.no

On Fri, 25 Jan 2002, Are Bryne wrote:

> On Fri, 25 Jan 2002, Tom Lane wrote:
>
> > In the meantime perhaps you can survive without ssl support ...
>
> I'll try.

That did it...

Though when running:
# su -l pgsql -c initdb
This database system will be initialized with username "pgsql".
This user will own all the data files and must also own the server
process.

Creating directory /usr/local/pgsql/data
Creating directory /usr/local/pgsql/data/base
Creating directory /usr/local/pgsql/data/global
Creating directory /usr/local/pgsql/data/pg_xlog
Creating template1 database in /usr/local/pgsql/data/base/1
Bad system call - core dumped

initdb failed.
Removing /usr/local/pgsql/data.
Removing temp file /tmp/initdb.27045.

No directories were created under /usr/local/pgsql ...

I'll do some research to see if this is a FAQ or a known issue.
Unfortunately, I'm no good at debugging.

this seems ok:
# ldd `which postgres`
/usr/local/bin/postgres:
-lz.2 => /usr/lib/libz.so.2.0 (0x201a8000)
-lcrypt.2 => /usr/lib/libcrypt.so.2.0 (0x201b4000)
-lm.2 => /usr/lib/libm.so.2.0 (0x201b7000)
-lutil.2 => /usr/lib/libutil.so.2.2 (0x201d2000)
-lreadline.3 => /usr/lib/libreadline.so.3.0 (0x201d8000)
-ltermcap.2 => /usr/lib/libtermcap.so.2.1 (0x201f7000)
-lc.3 => /usr/lib/libc.so.3.1 (0x201fb000)

> > regards, tom lane
> Are Bryne

Thank you for your time and help!

Regards,
Are Bryne
--
Communiqué DA Office: +47 22 44 33 99
Postboks 9050 Grønland Mobile: +47 900 22 009
NO-0133 Oslo URL: http://www.communique.no

Are Bryne <are-pgsql-ports(at)communique(dot)no> writes:
> Creating template1 database in /usr/local/pgsql/data/base/1
> Bad system call - core dumped

This one is a FAQ --- most likely, your kernel is compiled without SysV
shared memory/semaphore support.

regards, tom lane