Description of problem: Perl module Data::Alias was installed via CPAN on perl-5.12.3-141.fc14, and worked properly. Perl was upgraded to perl-5.12.3-142.fc14 via system update, causing Data::Alias to cease working. Version-Release number of selected component (if applicable): perl-5.12.3-142.fc14 How reproducible: We were able to reproduce this on a fresh install of Perl 5.12.3 on FC14. Steps to Reproduce: 1. Install perl-5.12.3-141.fc14 2. Install Data::Alias _using CPAN_ (e.g. perl -MCPAN -e 'install Data::Alias') 3. Verify Data::Alias works (e.g. perl -MData::Alias -le 1) 4. Upgrade to perl-5.12.3-142.fc14 (e.g. yum upgrade perl) 5. Test Data::Alias again Actual results: Can't load '/usr/local/lib64/perl5/auto/Data/Alias/Alias.so' for module Data::Alias: /usr/local/lib64/perl5/auto/Data/Alias/A lias.so: undefined symbol: perl_sub__return_semaphore at /usr/lib64/perl5/DynaLoader.pm line 200. at -e line 0 Compilation failed in require. BEGIN failed--compilation aborted. Expected results: no output / error Additional info: In between steps 3 and 4, you can also verify that the undefined symbol in question is being referenced even when everything works properly: # nm blib/arch/auto/Data/Alias/Alias.so | grep semaphore U perl_sub__return_semaphore We can't determine what library is actually providing the symbol, but something must be, because everything works at that point. After upgrading to 142, the symbol reference is still there in Data::Alias's shared library, but apparently whatever was providing it is now gone. We also tried uninstalling Data::Alias and then reinstalling it, but this just causes the error during the CPAN build and the module cannot be reinstalled. Reinstalling perl 142 does not help. So far we've seen this on two machines, both multi-threaded Perl 5.12.3 on x86_64. Me: Perl programmer, working with local Linux sys admin.
We removed Data::Alias from distribution, because it doesn't work with 5.12.x at all. See https://bugzilla.redhat.com/show_bug.cgi?id=611014 But if I install Data::Alias from cpan and run it with 5.13.x, it does work.
The only change in perl was ExtUtils::ParseXS upgrade to 2.2206. The undefined symbol comes from systemtap headers while compiling Alias.c: # 139 "/usr/include/sys/sdt.h" 3 4 # 1 "/usr/include/sys/sdt-config.h" 1 3 4 # 140 "/usr/include/sys/sdt.h" 2 3 4 # 10 "/usr/lib64/perl5/CORE/perldtrace.h" 2 # 18 "/usr/lib64/perl5/CORE/perldtrace.h" __extension__ extern unsigned short perl_sub__entry_semaphore __attribute__ ((unused)) __attribute__ ((section (".probes"))); # 29 "/usr/lib64/perl5/CORE/perldtrace.h" __extension__ extern unsigned short perl_sub__return_semaphore __attribute__ ((unused)) __attribute__ ((section (".probes")));
Lukas, is it possible that there is bug in systemtap support for Perl? The upgrade to new parser of XS files could make the problem visible. At the moment we are not aware of any other "broken" modules.
The _foo_semaphore symbols are defined in an .o file that may be produced from the dtrace .d probe specification via /usr/bin/dtrace -G. This object file would need to be linked into the respective library/binary. systemtap 1.4 changed the elf symbol visibility of these symbols to "hidden". Perhaps former builds of the perl module accidentally relied on these being non-hidden, and thus satisfied by the libperl.so copy of those symbols.
(In reply to comment #1) > We removed Data::Alias from distribution, because it doesn't work with 5.12.x > at all. ... This is incorrect. I'm familiar with the bug you reference, but that was at a time when Data::Alias had not been updated in 3 years. Now a new maintainer has taken it over, and 5 new versions have been released since then. And the fact of the matter is that it _does_ work with perl-5.12.3-141.fc14: I _had_ it working perfectly until the security upgrade came along and broke it. :-( But note that the problem only manifests when Data::Alias is installed from CPAN. If installed via yum (on perl-5.12.3-141.fc14), Data::Alias works, but the Alias.so does _not_ contain the reference to the undefined symbol, so I doubt the upgrade would break it in that instance. I have no idea what the difference is.
(In reply to comment #4) > The _foo_semaphore symbols are defined in an .o file that may be produced from > the dtrace .d probe specification via /usr/bin/dtrace -G. This object file > would > need to be linked into the respective library/binary. > > systemtap 1.4 changed the elf symbol visibility of these symbols to "hidden". > Perhaps former builds of the perl module accidentally relied on these being > non-hidden, and thus satisfied by the libperl.so copy of those symbols. Interesting. I know we need to find a permanent solution, but can I implement a temporary workaround by linking in the object file you mention above? How would I go about doing that?
Okay, we've been working a bit more on this problem; the additional info provided above has been quite helpful. The first thing we tried is, removing systemtap. I have no need for it, really. So I just did this: yum remove systemtap systemtap-runtime systemtap-sdt-devel All 3 removed cleanly, no dependencies on them were identified. Now, I try to reinstall Data::Alias again (via CPAN). Now I get a new error: /usr/bin/perl "-Iinc" /usr/share/perl5/ExtUtils/xsubpp -typemap /usr/share/perl5/ExtUtils/typemap Alias.xs > Alias.xsc && mv Alias.xsc Alias.c gcc -c -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DVERSION=\"1.12\" -DXS_VERSION=\"1.12\" -fPIC "-I/usr/lib64/perl5/CORE" Alias.c In file included from /usr/lib64/perl5/CORE/mydtrace.h:14:0, from /usr/lib64/perl5/CORE/cop.h:138, from /usr/lib64/perl5/CORE/perl.h:3428, from Alias.xs:14: /usr/lib64/perl5/CORE/perldtrace.h:9:21: fatal error: sys/sdt.h: No such file or directory compilation terminated. make: *** [Alias.o] Error 1 And, now that I see this error, I remember that _this_ is why I installed systemtap in the first place. Now, tracking back the error as best we can, we see this in /usr/lib64/perl5/CORE/mydtrace.h: #if defined(USE_DTRACE) && defined(PERL_CORE) Basically, it looks like if USE_DTRACE weren't defined, there'd be no problem. So we did this: perl -V | grep -i trace config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Dccdlflags=-Wl,--enable-new-dtags -DDEBUGGING=-g -Dversion=5.12.3 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5 -Darchlib=/usr/lib64/perl5 -Dvendorarch=/usr/lib64/perl5 -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Dusedtrace=/usr/bin/dtrace -Duselargefiles -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dotherlibdirs=/usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi:/usr/local/lib/perl5/site_perl/5.10.0:/usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi:/usr/lib/perl5/vendor_perl:/usr/lib/perl5/site_perl' So it looks to us like the -Dusedtrace=/usr/bin/dtrace might be the source of the problem. Now, I personally don't have any need of this flag in my Perl, AFAIK, and I'd be surprised if most other Perl programmers did either. Is it possible to get the Perl built without it? If not, we need to figure out a way to make everyone play nice together. :)
The perl module building mechanisms are supposed to do the proper sys/sdt.h make/options, so individual perl module writers don't have to worry about it. Something in the perl system is just a little bit wrong. I'm not familiar enough with it to point a finger, but wherever the .pm compile/link stuff is kept is where I'd start looking.
(In reply to comment #8) > The perl module building mechanisms are supposed to do the proper sys/sdt.h > make/options, No they're not. Perl modules shouldn't be exposed to sys/sdt.h at all. The problem here seems to be that Data::Alias cheats by defining PERL_CORE and using POPSUB. It's Data::Alias' problem and can easily be worked around by: --- Alias.xs.orig 2011-02-22 21:41:15.000000000 +0100 +++ Alias.xs 2011-04-13 14:36:41.570559332 +0200 @@ -14,6 +14,7 @@ #include "perl.h" #include "XSUB.h" +#define RETURN_PROBE(func, file, line) #ifdef USE_5005THREADS #error "5.005 threads not supported by Data::Alias"
(In reply to comment #9) > (In reply to comment #8) > > The perl module building mechanisms are supposed to do the proper sys/sdt.h > > make/options, > > No they're not. Perl modules shouldn't be exposed to sys/sdt.h at all. Then it seems to me that Perl should not be built with -Dusedtrace; this would cause the mydtrace.h to skip including sys/sdt.h (see comment #7). > The problem here seems to be that Data::Alias cheats by defining PERL_CORE and > using POPSUB. It's Data::Alias' problem and can easily be worked around by: I'll open a bug on CPAN's RT for Data::Alias' author. But I still don't see why Perl is bringing in dtrace at all.
(In reply to comment #10) > I'll open a bug on CPAN's RT for Data::Alias' author. But I still don't see > why Perl is bringing in dtrace at all. Systemtap makes use of the same sdt style markers for probing purposes. By enabling -Dusedtrace, users of Systemtap can probe their perl applications as well.
Well, I can confirm that if I patch the Alias.xs as recommended in comment #9 _and_ I reinstall systemtap-sdt-devel, then it installs and runs fine. (Apparently systemtap and systemtap-runtime are not actually required.) I also note that one of you fine Redhat folks already created a bug against Data::Alias in CPAN RT, so thanks for that. I assume that this breakage slipped through the cracks because the RPM version of Data::Alias was removed, as per the bug mentioned in comment #1. Since the newer versions of Data::Alias seem to work with Perl 5.12, perhaps that package should be resurrected. Anyway, thanks everyone for their time.
If this package is used, I could re-add it into Fedora. Would be anyone interested in review #202876?
Upstream fixed it in new release.