Thread: plperl needs upgrade for Fedora 10
Hello I am testing PostgreSQL on Federa 10. There is Perl 5.10. After successful compilation I got error CREATE LANGUAGE plperl; ERROR: could not oad library "/........plperl.so": ... undefined symbol: boot_DynaLoader Regards Pavel Stehule
Pavel Stehule wrote: > Hello > > I am testing PostgreSQL on Federa 10. There is Perl 5.10. After > successful compilation I got error > > CREATE LANGUAGE plperl; > ERROR: could not oad library "/........plperl.so": ... undefined > symbol: boot_DynaLoader > > Regards > Pavel Stehule > > Please send the build log for plperl also, and you configure settings. I have previously built against perl 5.10 quite happily. cheers andrew
postgres=# select version();
version
----------------------------------------------------------------------------------------------------------
PostgreSQL 8.3.4 on x86_64-unknown-linux-gnu, compiled by GCC gcc
(GCC) 4.3.2 20080917 (Red Hat 4.3.2-4)
(1 row)
postgres=# CREATE LANGUAGE plperlu;
ERROR: could not load library "/usr/local/pgsql8.3/lib/plperl.so":
/usr/local/pgsql8.3/lib/plperl.so: undefined symbol: boot_DynaLoader
postgres=#
Regards
Pavel Stehule
2008/11/3 Andrew Dunstan <andrew@dunslane.net>:
>
>
> Pavel Stehule wrote:
>>
>> Hello
>>
>> I am testing PostgreSQL on Federa 10. There is Perl 5.10. After
>> successful compilation I got error
>>
>> CREATE LANGUAGE plperl;
>> ERROR: could not oad library "/........plperl.so": ... undefined
>> symbol: boot_DynaLoader
>>
>> Regards
>> Pavel Stehule
>>
>>
>
> Please send the build log for plperl also, and you configure settings. I
> have previously built against perl 5.10 quite happily.
>
> cheers
>
> andrew
>
Attachment
Pavel Stehule wrote: > postgres=# select version(); > version > ---------------------------------------------------------------------------------------------------------- > PostgreSQL 8.3.4 on x86_64-unknown-linux-gnu, compiled by GCC gcc > (GCC) 4.3.2 20080917 (Red Hat 4.3.2-4) > (1 row) > > postgres=# CREATE LANGUAGE plperlu; > ERROR: could not load library "/usr/local/pgsql8.3/lib/plperl.so": > /usr/local/pgsql8.3/lib/plperl.so: undefined symbol: boot_DynaLoader > postgres=# > 1. Please do not top-answer. 2. You have not provided the info I asked for, namely the configure params and the build log. e.g.: configure --enable-cassert --enable-debug --enable-nls --enable-integer-datetimes \ --with-perl --with-python --with-tcl\ --with-krb5 --with-includes=/usr/include/et --with-openssl \ --with-pam --with-ldap --with-libxml--with-libxslt --with-ossp-uuid --with-gssapi --enable-depend --prefix=/home/andrew/bf/root/HEAD/inst --with-pgport=5678 make[3]: Entering directory `/home/andrew/bf/root/HEAD/pgsql.24747/src/pl/plperl' ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing-fwrapv -g -fpic -I/home/andrew/bf/root/HEAD/pgsql.24747/../pgsql/src/pl/plperl -I../../../src/include-I/home/andrew/bf/root/HEAD/pgsql.24747/../pgsql/src/include -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/et -I/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE -c -o plperl.o /home/andrew/bf/root/HEAD/pgsql.24747/../pgsql/src/pl/plperl/plperl.c-MMD -MP -MF .deps/plperl.Po ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing-fwrapv -g -fpic -I/home/andrew/bf/root/HEAD/pgsql.24747/../pgsql/src/pl/plperl -I../../../src/include-I/home/andrew/bf/root/HEAD/pgsql.24747/../pgsql/src/include -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/et -I/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE -c -o spi_internal.o /home/andrew/bf/root/HEAD/pgsql.24747/../pgsql/src/pl/plperl/spi_internal.c-MMD -MP -MF .deps/spi_internal.Po "/usr/bin/perl" /usr/lib/perl5/5.8.8/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.8.8/ExtUtils/typemap /home/andrew/bf/root/HEAD/pgsql.24747/../pgsql/src/pl/plperl/SPI.xs>SPI.c ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing-fwrapv -g -fpic -I/home/andrew/bf/root/HEAD/pgsql.24747/../pgsql/src/pl/plperl -I../../../src/include-I/home/andrew/bf/root/HEAD/pgsql.24747/../pgsql/src/include -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/et -I/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE -c -o SPI.o SPI.c -MMD -MP -MF .deps/SPI.Po ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing-fwrapv -g -fpic -shared plperl.o spi_internal.o SPI.o -L/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE-L../../../src/port /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/auto/DynaLoader/DynaLoader.a-lperl -lresolv -lnsl -ldl -lm -lcrypt -lutil-lpthread -lc -Wl,-rpath,'/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE' -o plperl.so make[3]: Leaving directory `/home/andrew/bf/root/HEAD/pgsql.24747/src/pl/plperl' cheers andrew
Andrew Dunstan wrote: > > > > 2. You have not provided the info I asked for, namely the configure > params and the build log. e.g.: > > My apologies. I missed the attachments with this info. cheers andrew
2008/11/4 Andrew Dunstan <andrew@dunslane.net>: > > > Andrew Dunstan wrote: >> >> >> >> 2. You have not provided the info I asked for, namely the configure params >> and the build log. e.g.: >> >> > > My apologies. I missed the attachments with this info. no problem Pavel > > cheers > > andrew >
Pavel Stehule wrote: > 2008/11/4 Andrew Dunstan <andrew@dunslane.net>: > >> Andrew Dunstan wrote: >> >>> >>> 2. You have not provided the info I asked for, namely the configure params >>> and the build log. e.g.: >>> >>> >>> >> My apologies. I missed the attachments with this info. >> > > no problem > > > Please send the output of the following: perl -V nm /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE/libperl.so | grep boot_Dyn cheers andrew
Pavel Stehule wrote: > postgres=# select version(); > version > ---------------------------------------------------------------------------------------------------------- > PostgreSQL 8.3.4 on x86_64-unknown-linux-gnu, compiled by GCC gcc > (GCC) 4.3.2 20080917 (Red Hat 4.3.2-4) > (1 row) > > postgres=# CREATE LANGUAGE plperlu; > ERROR: could not load library "/usr/local/pgsql8.3/lib/plperl.so": > /usr/local/pgsql8.3/lib/plperl.so: undefined symbol: boot_DynaLoader > postgres=# > > >> OK, I have got to the bottom of this. It appears that the Fedora people have for some reason best known to themselves decided to stop bundling the ExtUtils::Embed module with base perl, as it was before. Once this module is installed plperl builds and performs just fine. Maybe someone with Fedora connections could ask them why they would do such an odd thing. It's not like they are saving a huge amount of space. Meanwhile, I think we should make our call to it in the config file more robust, so we detect the call failure. cheers andrew
2008/11/6 Andrew Dunstan <andrew@dunslane.net>: > > > Pavel Stehule wrote: >> >> postgres=# select version(); >> version >> >> ---------------------------------------------------------------------------------------------------------- >> PostgreSQL 8.3.4 on x86_64-unknown-linux-gnu, compiled by GCC gcc >> (GCC) 4.3.2 20080917 (Red Hat 4.3.2-4) >> (1 row) >> >> postgres=# CREATE LANGUAGE plperlu; >> ERROR: could not load library "/usr/local/pgsql8.3/lib/plperl.so": >> /usr/local/pgsql8.3/lib/plperl.so: undefined symbol: boot_DynaLoader >> postgres=# >> >> >>> >>> > > OK, I have got to the bottom of this. It appears that the Fedora people have > for some reason best known to themselves decided to stop bundling the > ExtUtils::Embed module with base perl, as it was before. > > Once this module is installed plperl builds and performs just fine. > > Maybe someone with Fedora connections could ask them why they would do such > an odd thing. It's not like they are saving a huge amount of space. > > Meanwhile, I think we should make our call to it in the config file more > robust, so we detect the call failure. > > cheers > > andrew > Now I am not at work, so I'll check it next week thank you Pavel
Andrew Dunstan <andrew@dunslane.net> writes:
> OK, I have got to the bottom of this. It appears that the Fedora people
> have for some reason best known to themselves decided to stop bundling
> the ExtUtils::Embed module with base perl, as it was before.
That's been true since F-9, so I'm not quite sure why Pavel's build only
broke at F-10. FWIW the postgresql Fedora RPMs have
BuildRequires: perl(ExtUtils::MakeMaker) glibc-devel bison flex autoconf gawk
BuildRequires: perl(ExtUtils::Embed), perl-devel
The extra Requires for MakeMaker has been there even longer.
> Meanwhile, I think we should make our call to it in the config file more
> robust, so we detect the call failure.
+1. Would be a good idea to check for MakeMaker too.
regards, tom lane
Tom Lane escribió: > Andrew Dunstan <andrew@dunslane.net> writes: > > OK, I have got to the bottom of this. It appears that the Fedora people > > have for some reason best known to themselves decided to stop bundling > > the ExtUtils::Embed module with base perl, as it was before. > > That's been true since F-9, so I'm not quite sure why Pavel's build only > broke at F-10. FWIW the postgresql Fedora RPMs have > > BuildRequires: perl(ExtUtils::MakeMaker) glibc-devel bison flex autoconf gawk > BuildRequires: perl(ExtUtils::Embed), perl-devel > > The extra Requires for MakeMaker has been there even longer. Huh, but the requirement for ExtUtils::Embed is at runtime, so shouldn't it be a plain Requires instead of BuildRequires? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
2008/11/6 Tom Lane <tgl@sss.pgh.pa.us>: > Andrew Dunstan <andrew@dunslane.net> writes: >> OK, I have got to the bottom of this. It appears that the Fedora people >> have for some reason best known to themselves decided to stop bundling >> the ExtUtils::Embed module with base perl, as it was before. > > That's been true since F-9, so I'm not quite sure why Pavel's build only > broke at F-10. FWIW the postgresql Fedora RPMs have > I skip F9. So I never used it. Pavel > BuildRequires: perl(ExtUtils::MakeMaker) glibc-devel bison flex autoconf gawk > BuildRequires: perl(ExtUtils::Embed), perl-devel > > The extra Requires for MakeMaker has been there even longer. > >> Meanwhile, I think we should make our call to it in the config file more >> robust, so we detect the call failure. > > +1. Would be a good idea to check for MakeMaker too. > > regards, tom lane >
Alvaro Herrera wrote: > Tom Lane escribió: > >> Andrew Dunstan <andrew@dunslane.net> writes: >> >>> OK, I have got to the bottom of this. It appears that the Fedora people >>> have for some reason best known to themselves decided to stop bundling >>> the ExtUtils::Embed module with base perl, as it was before. >>> >> That's been true since F-9, so I'm not quite sure why Pavel's build only >> broke at F-10. FWIW the postgresql Fedora RPMs have >> >> BuildRequires: perl(ExtUtils::MakeMaker) glibc-devel bison flex autoconf gawk >> BuildRequires: perl(ExtUtils::Embed), perl-devel >> >> The extra Requires for MakeMaker has been there even longer. >> > > Huh, but the requirement for ExtUtils::Embed is at runtime, so shouldn't > it be a plain Requires instead of BuildRequires? > > No. We need ExtUtils::Embed to get the linkage flags for the build. See config/perl.m4 cheers andrew
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane escribi�:
>> BuildRequires: perl(ExtUtils::MakeMaker) glibc-devel bison flex autoconf gawk
>> BuildRequires: perl(ExtUtils::Embed), perl-devel
> Huh, but the requirement for ExtUtils::Embed is at runtime, so shouldn't
> it be a plain Requires instead of BuildRequires?
Really? I'm pretty sure I recall the RPM build failing when they
changed that. (But it's possible that the regression test step is what
failed, I don't remember.) I'd think I'd have heard about it if there
were a missing runtime dependency.
BTW, Andrew was wondering *why* Fedora isn't bundling these anymore.
The CVS logs mention something about versioned perl, so it's possible
that they had to split out some modules to support multiple Perl
installations cleanly.
regards, tom lane
Tom Lane escribió: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > Tom Lane escribi�: > >> BuildRequires: perl(ExtUtils::MakeMaker) glibc-devel bison flex autoconf gawk > >> BuildRequires: perl(ExtUtils::Embed), perl-devel > > > Huh, but the requirement for ExtUtils::Embed is at runtime, so shouldn't > > it be a plain Requires instead of BuildRequires? > > Really? I'm pretty sure I recall the RPM build failing when they > changed that. Actually, seeing Andrew's response I think I'm probably wrong. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>
>> Tom Lane escribió:
>>
>>> BuildRequires: perl(ExtUtils::MakeMaker) glibc-devel bison flex autoconf gawk
>>> BuildRequires: perl(ExtUtils::Embed), perl-devel
>>>
>
>
>> Huh, but the requirement for ExtUtils::Embed is at runtime, so shouldn't
>> it be a plain Requires instead of BuildRequires?
>>
>
> Really? I'm pretty sure I recall the RPM build failing when they
> changed that. (But it's possible that the regression test step is what
> failed, I don't remember.) I'd think I'd have heard about it if there
> were a missing runtime dependency.
>
> BTW, Andrew was wondering *why* Fedora isn't bundling these anymore.
> The CVS logs mention something about versioned perl, so it's possible
> that they had to split out some modules to support multiple Perl
> installations cleanly.
>
>
>
My F9 instance has the module, from a separate RPM package, but I'm
fairly sure it came as part of the normal install. But the F10 install
DVD doesn't have it at all. I had to grab it from CPAN and build/install
manually to check that it was what was missing.
The really bad thing about this mess is that it doesn't make the build
fail - we don't get a failure until runtime, so unless the RPM build
checks run the Postgres PL install checks it wouldn't be caught.
I'm thinking of something like this change to config/perl.m4:
Index: config/perl.m4
===================================================================
RCS file: /cvsroot/pgsql/config/perl.m4,v
retrieving revision 1.3
diff -c -r1.3 perl.m4
*** config/perl.m4 29 Nov 2003 19:51:17 -0000 1.3
--- config/perl.m4 6 Nov 2008 17:14:34 -0000
***************
*** 32,35 **** pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'` perl_embed_ldflags=`echo X"$pgac_tmp1" | sed
"s/^X//;s%$pgac_tmp2%%"`AC_SUBST(perl_embed_ldflags)dnl
! AC_MSG_RESULT([$perl_embed_ldflags])])
--- 32,41 ---- pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'` perl_embed_ldflags=`echo X"$pgac_tmp1" | sed
"s/^X//;s%$pgac_tmp2%%"`AC_SUBST(perl_embed_ldflags)dnl
! if test -z "$perl_embed_ldflags" ; then
! AC_MSG_RESULT(no)
! AC_MSG_ERROR([unable to determine flags to link embedded Perl])
! else
! AC_MSG_RESULT([$perl_embed_ldflags])
! fi
! ])# PGAC_CHECK_PERL_EMBED_LDFLAGS
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> I'm thinking of something like this change to config/perl.m4:
> ! if test -z "$perl_embed_ldflags" ; then
> ! AC_MSG_RESULT(no)
> ! AC_MSG_ERROR([unable to determine flags to link embedded Perl])
Hm, is it certain that "empty" is never a valid value for
$perl_embed_ldflags? In any case I'm a bit confused how this fixes the
problem --- it looks like the test is just relying on Config not Embed.
regards, tom lane
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > >> I'm thinking of something like this change to config/perl.m4: >> > > >> ! if test -z "$perl_embed_ldflags" ; then >> ! AC_MSG_RESULT(no) >> ! AC_MSG_ERROR([unable to determine flags to link embedded Perl]) >> > > Hm, is it certain that "empty" is never a valid value for > $perl_embed_ldflags? Yes. If it's empty we don't even link against libperl at all. That can't possibly be right. > In any case I'm a bit confused how this fixes the > problem --- it looks like the test is just relying on Config not Embed. > > > No, we get the ldopts from Embed and then *remove* the ccldflags from Config from that string. What is left is set as perl_embed_flags, and that's what mustn't be empty. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> No, we get the ldopts from Embed and then *remove* the ccldflags from
> Config from that string. What is left is set as perl_embed_flags, and
> that's what mustn't be empty.
Got it. Sounds good then.
What about the MakeMaker dependency?
regards, tom lane
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > >> No, we get the ldopts from Embed and then *remove* the ccldflags from >> Config from that string. What is left is set as perl_embed_flags, and >> that's what mustn't be empty. >> > > Got it. Sounds good then. > > What about the MakeMaker dependency? > > > The call to ldopts will fail if MakeMaker is not present, so this will cover it. It's very unlikely to be absent - it's required to build almost every Perl module known to man. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> What about the MakeMaker dependency?
> The call to ldopts will fail if MakeMaker is not present, so this will
> cover it. It's very unlikely to be absent - it's required to build
> almost every Perl module known to man.
I see. I think then the error message should read something like
AC_MSG_ERROR([could not determine flags for linking embedded Perl
This probably means that ExtUtils::Embed or ExtUtils::MakeMaker is not
installed.])
Otherwise, looks good.
regards, tom lane
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > >> Tom Lane wrote: >> >>> What about the MakeMaker dependency? >>> > > >> The call to ldopts will fail if MakeMaker is not present, so this will >> cover it. It's very unlikely to be absent - it's required to build >> almost every Perl module known to man. >> > > I see. I think then the error message should read something like > > AC_MSG_ERROR([could not determine flags for linking embedded Perl > This probably means that ExtUtils::Embed or ExtUtils::MakeMaker is not > installed.]) > > Otherwise, looks good. > > > OK. Should we backpatch this? Arguably it's a build bug. (Also it would be good if someone were to whisper in the ears of the Fedora people that removing ExtUtils::Embed entirely from their Perl packaging is a dumb thing to do. This is a standard Perl module, that one would normally expect to accompany every Perl distribution.) cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> Otherwise, looks good.
> OK. Should we backpatch this? Arguably it's a build bug.
Yeah, probably.
> (Also it would be good if someone were to whisper in the ears of the
> Fedora people that removing ExtUtils::Embed entirely from their Perl
> packaging is a dumb thing to do. This is a standard Perl module, that
> one would normally expect to accompany every Perl distribution.)
So far as I can tell, Fedora has treated ExtUtils::Embed as a separate
RPM for a long time (at least since F-7). The recent change seems to be
that it's not required by perl-devel anymore, rather by perl-core (where
perl-core is defined as "everything in the upstream tarball from
perl.org"). So possibly it's just a matter of users not getting the
word as to what they should install.
regards, tom lane