Re: 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(at)dunslane(dot)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
>

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(at)dunslane(dot)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(at)dunslane(dot)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(at)dunslane(dot)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(at)dunslane(dot)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(at)dunslane(dot)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(at)sss(dot)pgh(dot)pa(dot)us>:
> Andrew Dunstan <andrew(at)dunslane(dot)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(at)dunslane(dot)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(at)commandprompt(dot)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(at)commandprompt(dot)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(at)commandprompt(dot)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(at)dunslane(dot)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(at)dunslane(dot)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(at)dunslane(dot)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(at)dunslane(dot)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(at)dunslane(dot)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(at)dunslane(dot)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(at)dunslane(dot)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