Description of problem: I am trying to build 386-ds-base on the BS and locally.But -lperl cannot find the libperl.so It solves the problem locally by doing: ln -sf /usr/lib/perl5/5.16.1/x86_64-linux-thread-multi/CORE/libperl.so /usr/lib/libperl.so A brand new installed mga2 does not have this problem Version-Release number of selected component (if applicable): Current cauldron How reproducible: Every time Steps to Reproduce: 1.Build the program locally using bm -bal or on the BS Here is fails /bin/sh ./libtool --tag=CC --mode=link x86_64-mageia-linux-gnu-gcc -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC -avoid-version -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags -o libstatechange-plugin.la -rpath /usr/lib64/dirsrv/plugins ldap/servers/plugins/statechange/libstatechange_plugin_la-statechange.lo libslapd.la /bin/ld: cannot find -lperl
wrong component according to your description
Component: New RPM package request => RPM PackagesAssignee: bugsquad => jquelin
Why is it the worn component. Looks to me to be a perl problem. As mentioned, it does build on mga2
Manuel, I agree. There is not change in perl since mga 2 that I could think of creating this. But what component is it?
I was meaning the bugzilla component sorry (new rpm package request vs rpm package) :)
No problem. Jerome, let me know if this isn't a Perl issue. It worked in mga2 and I don't see any changes that would suddenly not find the libperl.so anymore. libtool?
well, there's not that much change since mageia 2, besides switching to perl 5.16 i did not made a change regarding symbolic link for libperl.so
Let's close this as invalid and do more research which package has changed this behavier. We may have other packages showing this when they will be rebuilt.
Status: NEW => RESOLVEDResolution: (none) => INVALID