Thread: port report: [FAILURE] FreeBSD 6, Intel icc7
As per http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&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. -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com
Darcy Buskermolen <darcy@wavefire.com> writes: > As per > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&dt=2004-12-16%2018:46:18 > This combination of OS/compiler does not result in a working copy. The failure isascii_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&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, Pennsylvania19073
Tom Lane wrote: >Darcy Buskermolen <darcy@wavefire.com> writes: > > >>As per >>http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&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 requestfor 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 useof ccache) can be seen here: http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbuildfarm/client-code/build-farm.conf?rev=1.3&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&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&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, Pennsylvania19073
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 (showinguse of ccache) can be seen here: > http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbuildfarm/client-code/build-farm.conf?rev=1.3&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&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 (showinguse of ccache) can be seen here: >>http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbuildfarm/client-code/build-farm.conf?rev=1.3&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&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