[SOLVED] Vamp-plugins compile error on Current

business_kid · 08-05-2019, 11:50 AM

The git of vamp plugins is puking thusly:

Code:

bash-5.0$ make
ranlib ./libvamp-sdk.a
ranlib ./libvamp-hostsdk.a
g++   -o host/vamp-simple-host host/vamp-simple-host.o ./libvamp-hostsdk.a -lsndfile -ldl 
/usr/bin/ld: /usr/lib64/libm-2.29.a(s_sin.o): in function `__sin_ifunc':
(.text+0x12c3): undefined reference to `_dl_x86_cpu_features'
/usr/bin/ld: /usr/lib64/libm-2.29.a(s_sin.o): in function `__cos_ifunc':
(.text+0x1323): undefined reference to `_dl_x86_cpu_features'
collect2: error: ld returned 1 exit status
make: *** [Makefile:268: host/vamp-simple-host] Error 1

I find it hard to swallow that I have an old version of anything, given that I'm on current. In case it's relevant, I have had a little run-in with the libm stuff in glibc recently. Xsane puked for the lack of libm.so where it complained about the ELF header. Sure enough, /usr/lib64/libm.so is a 141 byte header(? ASCII anyhow) thing. I renamed that to /usr/libm/libm.so.1 and made /lib64/libm.so a symlink to /lib64/libm-2.29.so. That sorted my scanner out. I never touched any static (=.a) libs, which the compile is using.

EDIT: It appears this is an old bug in the static linking against libm going back at least to glibc-2.17. It happens in the 'sin' & 'cos' functions of libm.a, but not the tan.

Alien Bob · 08-06-2019, 06:12 AM

Is the stable release of vamp-plugins-sdk compiling correctly for you? When I built 2.8.0 in March, it compiled without errors.

business_kid · 08-06-2019, 08:54 AM

Nope. I still get the same error on libm.a with version 2.8. Libm.a is this:

Code:

/* GNU ld script
*/
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /usr/lib64/libm-2.29.a /usr/lib64/libmvec.a )

which to my untutored eye looks like a redirect to those 2 libs. I'm currently on July's current, and started backwards. April's Current had the same 102 byte script. But the libm.a from Slackware64-14.1 was 2.1 Megs, and THAT built it. That was glibc-2.19. I know it's hardly kosher to have a lib from glibc-2.19 in a 2.29 install, but it seems either ld isn't interpreting that script, or glibc is wrong. I'm using the multilib glibc install, but the 64 bit (only) glibc from current has an identical libm.a.

Audacity now starts, which is why I wanted this stupid thing anyhow. So this particular problem is solved. But whereas I may have dodged the issue this time, I would like to be able to link against static libs in the future if software heads are going to create stuff linked against them.

Anyhow, since it is now linked, I don't actually need libm.a, and can put back the script and everything (except linking!) will still work.

business_kid · 08-06-2019, 02:32 PM

I went back to this compile and tried a symlink to libm-2.29.a which is in that ld script. It puked lacking the same symbol at line 268. I tried the symlink to libmvec.a, and that puked on line 271 of the Makefile lacking another symbol. It appears they have split the thing up, and the script isn't working. Now before anyone starts grasping at straws, this failed using my backup of Compat32 from July. Yesterday, not trusting anything, I downloaded the same file again, and installed over. No change.

Now RHEL say they "don't support static linking." Does Slackware?

Alien Bob · 08-06-2019, 02:50 PM

I downloaded the repository snapshot of vamp-plugins-sdk, changed the VERSION of my SlackBuild script, and it compiled on this slackware64-current laptop with multilib, in about 10 seconds.
This is what happens here around the moment where you get that error (exaxt same output as I saw when compiling the stable 2.8 by the way):

Code:

ranlib ./libvamp-sdk.a
ranlib ./libvamp-hostsdk.a
g++  -static-libgcc -shared -Wl,-Bsymbolic -Wl,--version-script=build/vamp-plugin.map -o examples/vamp-example-plugins.so examples/SpectralCentroid.o examples/PowerSpectrum.o examples/PercussionOnsetDetector.o examples/FixedTempoEstimator.o examples/AmplitudeFollower.o examples/ZeroCrossing.o examples/plugins.o ./libvamp-sdk.a
g++   -o host/vamp-simple-host host/vamp-simple-host.o ./libvamp-hostsdk.a -lsndfile -ldl 
g++   -o rdf/generator/vamp-rdf-template-generator rdf/generator/vamp-rdf-template-generator.o ./libvamp-hostsdk.a -ldl 
VAMP_PATH=examples host/vamp-simple-host -l

Vamp plugin search path: [examples]

Vamp plugin libraries found in search path:

  examples/vamp-example-plugins.so:

I said it before - your system is broken. Best if you re-install from scratch instead of desperately trying to move back and forth between older and newer -current package sets.

business_kid · 08-07-2019, 05:10 AM

You're probably right.

business_kid · 08-07-2019, 11:21 AM

Ok, I really didn't want to go the clean reinstall, as I have a number of suites for learning & testing installed here ATM.
So I loop mounted the Current(16/07) DVD iso started an 'upgradepkg --reinstall' on everything and went out to lunch. When I got back, I did likewise for the compat32, which of course had glibc & gcc installed over.

The vamp package built here without issue now. I'm also running on Mesa-19.1.2. It seems like you suspected, the reinstall was the way to go.