port report: [FAILURE] FreeBSD 6, Intel icc7

Darcy Buskermolen <darcy@wavefire.com> writes:

As per
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&amp;dt=2004-12-16%2018:46:18
This combination of OS/compiler does not result in a working copy.

The failure is
ascii_and_mic.so: Undefined symbol "pg_mic2ascii"

I think you are in need of the local equivalent to GNU ld's -E or
--export-dynamic switch, ie, make sure that all global symbols within
the backend will be available to dynamically loaded libraries.

BTW, how did you get configure to choose icc? If you used a CC
environment variable, it seems like the buildfarm output is missing
important information by not reporting it.

regards, tom lane

Darcy Buskermolen wrote:

As per
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&amp;dt=2004-12-16%2018:46:18

This combination of OS/compiler does not result in a working copy.

Andrew and i have been digging into this for better than a week now, and
something just dosent look right.

That is strange. The problem line appears to be:

creating conversions ... FATAL: could not load library
... /postgresql/ascii_and_mic.so":dlopen
... /postgresql/ascii_and_mic.so'failed.
... /postgresql/ascii_and_mic.so:Undefined symbol "pg_mic2ascii")

I wonder if running ldconfig would help.

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

Darcy Buskermolen <darcy@wavefire.com> writes:

As per
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&amp;dt=2004-12-16%2018:46:18
This combination of OS/compiler does not result in a working copy.

The failure is
ascii_and_mic.so: Undefined symbol "pg_mic2ascii"

I think you are in need of the local equivalent to GNU ld's -E or
--export-dynamic switch, ie, make sure that all global symbols within
the backend will be available to dynamically loaded libraries.

BTW, how did you get configure to choose icc? If you used a CC
environment variable, it seems like the buildfarm output is missing
important information by not reporting it.

That log shows:

ccache icc -g -fpic -DPIC -I../../../src/interfaces/libpq -I../../../src/include -c -o regress.o regress.c
xild -x -shared -o regress.so regress.o

The status page also says this regarding the member:

FreeBSD 6-CURRENT Intel(tm) CC 7.1 Build 20040901Z ia32

I can highlight this and more info if required - just tell me what you want to know. I already have on my list your request for version numbers for changed files.

It's a bit of a balancing act between providing too much info and not enough.

To answer your question about how to choose it, you do it through the buildfarm member's config file - example (showing use of ccache) can be seen here:
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbuildfarm/client-code/build-farm.conf?rev=1.3&amp;content-type=text/x-cvsweb-markup

cheers

andrew

Bruce Momjian wrote:

Darcy Buskermolen wrote:

As per
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&amp;dt=2004-12-16%2018:46:18

This combination of OS/compiler does not result in a working copy.

Andrew and i have been digging into this for better than a week now, and
something just dosent look right.

That is strange. The problem line appears to be:

creating conversions ... FATAL: could not load library
... /postgresql/ascii_and_mic.so":dlopen
... /postgresql/ascii_and_mic.so'failed.
... /postgresql/ascii_and_mic.so:Undefined symbol "pg_mic2ascii")

I wonder if running ldconfig would help.

What would it do? This is failing at the "make check" stage, before it's
even installed (and buildfarm doesn't install to a standard location
anyway).

cheers

andrew

Andrew Dunstan wrote:

Bruce Momjian wrote:

Darcy Buskermolen wrote:

As per
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&amp;dt=2004-12-16%2018:46:18

This combination of OS/compiler does not result in a working copy.

Andrew and i have been digging into this for better than a week now, and
something just dosent look right.

That is strange. The problem line appears to be:

creating conversions ... FATAL: could not load library
... /postgresql/ascii_and_mic.so":dlopen
... /postgresql/ascii_and_mic.so'failed.
... /postgresql/ascii_and_mic.so:Undefined symbol "pg_mic2ascii")

I wonder if running ldconfig would help.

What would it do? This is failing at the "make check" stage, before it's
even installed (and buildfarm doesn't install to a standard location
anyway).

Sometimes pre-existing libraries that are already installed override
even the regression initdb on some platforms. It is just a guess.

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

Andrew Dunstan <andrew@dunslane.net> writes:

To answer your question about how to choose it, you do it through the buildfarm member's config file - example (showing use of ccache) can be seen here:
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbuildfarm/client-code/build-farm.conf?rev=1.3&amp;content-type=text/x-cvsweb-markup

I see. Would it be reasonable for the buildfarm members to provide
links to the config files they're using? You'd have to do something
about separating out the passwords :-(

regards, tom lane

On December 16, 2004 01:49 pm, Bruce Momjian wrote:

Andrew Dunstan wrote:

Bruce Momjian wrote:

Darcy Buskermolen wrote:

As per
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&amp;dt=2004-12-16
%2018:46:18

This combination of OS/compiler does not result in a working copy.

Andrew and i have been digging into this for better than a week now,
and something just dosent look right.

That is strange. The problem line appears to be:

creating conversions ... FATAL: could not load library
... /postgresql/ascii_and_mic.so":dlopen
... /postgresql/ascii_and_mic.so'failed.
... /postgresql/ascii_and_mic.so:Undefined symbol "pg_mic2ascii")

I wonder if running ldconfig would help.

What would it do? This is failing at the "make check" stage, before it's
even installed (and buildfarm doesn't install to a standard location
anyway).

Sometimes pre-existing libraries that are already installed override
even the regression initdb on some platforms. It is just a guess.

And in this case it's a "virgin", not having an installed copy of pg.

--
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx: 250.763.1759
http://www.wavefire.com

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

To answer your question about how to choose it, you do it through the buildfarm member's config file - example (showing use of ccache) can be seen here:
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbuildfarm/client-code/build-farm.conf?rev=1.3&amp;content-type=text/x-cvsweb-markup

I see. Would it be reasonable for the buildfarm members to provide
links to the config files they're using? You'd have to do something
about separating out the passwords :-(

Not a link, but I could easily have them report the contents of the
config hash, with the password removed. Feature request filed on pgfoundry.

cheers

andrew

On December 16, 2004 12:37 pm, Tom Lane wrote:

Darcy Buskermolen <darcy@wavefire.com> writes:

As per
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&amp;dt=2004-12-16%2
018:46:18 This combination of OS/compiler does not result in a working
copy.

The failure is
ascii_and_mic.so: Undefined symbol "pg_mic2ascii"

I think you are in need of the local equivalent to GNU ld's -E or
--export-dynamic switch, ie, make sure that all global symbols within
the backend will be available to dynamically loaded libraries.

basicly it's done via a
CC=icc LD=xild ./configure .......

and for refrence find attached the icc -help output.

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

--
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx: 250.763.1759
http://www.wavefire.com

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Andrew Dunstan wrote:

What would it do? This is failing at the "make check" stage, before it's
even installed (and buildfarm doesn't install to a standard location
anyway).

Sometimes pre-existing libraries that are already installed override
even the regression initdb on some platforms. It is just a guess.

The "undefined" symbol is in the main backend, not in any shared
library.

regards, tom lane

Darcy Buskermolen <darcy@wavefire.com> writes:

On December 16, 2004 12:37 pm, Tom Lane wrote:

I think you are in need of the local equivalent to GNU ld's -E or
--export-dynamic switch, ie, make sure that all global symbols within
the backend will be available to dynamically loaded libraries.

basicly it's done via a
CC=icc LD=xild ./configure .......

and for refrence find attached the icc -help output.

That's the wrong list --- what about the linker's options?

regards, tom lane

On December 16, 2004 02:28 pm, Tom Lane wrote:

Darcy Buskermolen <darcy@wavefire.com> writes:

On December 16, 2004 12:37 pm, Tom Lane wrote:

I think you are in need of the local equivalent to GNU ld's -E or
--export-dynamic switch, ie, make sure that all global symbols within
the backend will be available to dynamically loaded libraries.

basicly it's done via a
CC=icc LD=xild ./configure .......

and for refrence find attached the icc -help output.

That's the wrong list --- what about the linker's options?

xild just gets envoked as a wrapper to gnu ld by the looks of it.

But just incase:

regards, tom lane

--
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx: 250.763.1759
http://www.wavefire.com

Darcy Buskermolen <darcy@wavefire.com> writes:

On December 16, 2004 12:37 pm, Tom Lane wrote:
I think you are in need of the local equivalent to GNU ld's -E or
--export-dynamic switch, ie, make sure that all global symbols within
the backend will be available to dynamically loaded libraries.

xild just gets envoked as a wrapper to gnu ld by the looks of it.

Hmm. I see in Makefile.freebsd:

ifdef ELF_SYSTEM
export_dynamic = -export-dynamic
rpath = -R$(rpathdir)
shlib_symbolic = -Wl,-Bsymbolic -lc
endif

Perhaps ELF_SYSTEM isn't getting defined? Or maybe it's being picky
about seeing --export-dynamic instead of -export-dynamic ? Or you need
to spell it like "-Wl,-E" to get it past icc and into the linker?
You did not show the build log, but take a look at how the postgres
executable is getting linked to see if -export-dynamic is getting in
there or not.

regards, tom lane

On December 16, 2004 04:29 pm, Tom Lane wrote:

Darcy Buskermolen <darcy@wavefire.com> writes:

On December 16, 2004 12:37 pm, Tom Lane wrote:
I think you are in need of the local equivalent to GNU ld's -E or
--export-dynamic switch, ie, make sure that all global symbols within
the backend will be available to dynamically loaded libraries.

xild just gets envoked as a wrapper to gnu ld by the looks of it.

Hmm. I see in Makefile.freebsd:

ifdef ELF_SYSTEM
export_dynamic = -export-dynamic
rpath = -R$(rpathdir)
shlib_symbolic = -Wl,-Bsymbolic -lc
endif

Perhaps ELF_SYSTEM isn't getting defined? Or maybe it's being picky
about seeing --export-dynamic instead of -export-dynamic ? Or you need
to spell it like "-Wl,-E" to get it past icc and into the linker?
You did not show the build log, but take a look at how the postgres
executable is getting linked to see if -export-dynamic is getting in
there or not.

Ok we are making further headway:

gmake[3]: Leaving directory
`/buildfarm/pg-buildfarm/HEAD/pgsql.639/src/timezone'
icc -O -L../../src/port -R/usr/local/pgsql/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 storag
e/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o ../../src/timezone/SUBSYS.o
-lpgport_srv -lz -lreadline -lcrypt -lcompat -lm -lutil -o postgres

iccbin: Command line warning: ignoring unknown option '-R/usr/local/pgsql/lib'
/usr/local/intel/compiler70/ia32/bin/ldwrapper/ld: warning: cannot find entry
symbol xport-dynamic; defaulting to 000000000804acc0

gmake[2]: Leaving directory
`/buildfarm/pg-buildfarm/HEAD/pgsql.639/src/backend'
gmake -C backend/utils/mb/conversion_procs all

So it looks like icc dosn't like -export-dynamic

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

--
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx: 250.763.1759
http://www.wavefire.com

Darcy Buskermolen <darcy@wavefire.com> writes:

On December 16, 2004 04:29 pm, Tom Lane wrote:

Hmm. I see in Makefile.freebsd:

ifdef ELF_SYSTEM
export_dynamic = -export-dynamic
rpath = -R$(rpathdir)
shlib_symbolic = -Wl,-Bsymbolic -lc
endif

Ok we are making further headway:

icc -O -L../../src/port -R/usr/local/pgsql/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 storag
e/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o ../../src/timezone/SUBSYS.o
-lpgport_srv -lz -lreadline -lcrypt -lcompat -lm -lutil -o postgres

iccbin: Command line warning: ignoring unknown option '-R/usr/local/pgsql/lib'
/usr/local/intel/compiler70/ia32/bin/ldwrapper/ld: warning: cannot find entry
symbol xport-dynamic; defaulting to 000000000804acc0

So it looks like icc dosn't like -export-dynamic

Looks like it doesn't like -R either. You need to determine the correct
alternative spelling of those switches for us, and then we can put a
conditional into Makefile.freebsd for icc.

Is icc available on any other platforms besides FreeBSD?

regards, tom lane

On December 21, 2004 09:50 am, Tom Lane wrote:

Darcy Buskermolen <darcy@wavefire.com> writes:

On December 16, 2004 04:29 pm, Tom Lane wrote:

Hmm. I see in Makefile.freebsd:

ifdef ELF_SYSTEM
export_dynamic = -export-dynamic
rpath = -R$(rpathdir)
shlib_symbolic = -Wl,-Bsymbolic -lc
endif

Ok we are making further headway:

icc -O -L../../src/port -R/usr/local/pgsql/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 storag
e/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o ../../src/timezone/SUBSYS.o
-lpgport_srv -lz -lreadline -lcrypt -lcompat -lm -lutil -o postgres

iccbin: Command line warning: ignoring unknown option
'-R/usr/local/pgsql/lib'
/usr/local/intel/compiler70/ia32/bin/ldwrapper/ld: warning: cannot find
entry symbol xport-dynamic; defaulting to 000000000804acc0

So it looks like icc dosn't like -export-dynamic

Looks like it doesn't like -R either. You need to determine the correct
alternative spelling of those switches for us, and then we can put a
conditional into Makefile.freebsd for icc.

-Wl,-export-dynamic looks to do the job

Is icc available on any other platforms besides FreeBSD?

Yes icc is available for other platforms, most notably linux and MS windows.

regards, tom lane

--
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx: 250.763.1759
http://www.wavefire.com

Tom Lane wrote:

So it looks like icc dosn't like -export-dynamic

Looks like it doesn't like -R either. You need to determine the
correct alternative spelling of those switches for us, and then we
can put a conditional into Makefile.freebsd for icc.

Considering that these are all really linker options, adding -Wl, in
each case should do. Various compilers are known to let various linker
options slip by, but using -Wl is always correct.

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

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane wrote:

So it looks like icc dosn't like -export-dynamic

Looks like it doesn't like -R either. You need to determine the
correct alternative spelling of those switches for us, and then we
can put a conditional into Makefile.freebsd for icc.

Considering that these are all really linker options, adding -Wl, in
each case should do. Various compilers are known to let various linker
options slip by, but using -Wl is always correct.

I was just going to ask whether we needed to conditionalize it or not.

I will add -Wl, to 'em all. The build farm will let us know soon enough
if that's bad ;-)

regards, tom lane

Darcy Buskermolen <darcy@wavefire.com> writes:

So it looks like icc dosn't like -export-dynamic

Patch applied, let us know how it goes ...

regards, tom lane

On December 21, 2004 10:58 am, Tom Lane wrote:

Darcy Buskermolen <darcy@wavefire.com> writes:

So it looks like icc dosn't like -export-dynamic

Patch applied, let us know how it goes ...

Buildfarm member herring now passes all checks and returns a green light.

regards, tom lane

--
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx: 250.763.1759
http://www.wavefire.com