Gentoo Forums :: View topic - media-libs/rubberband fails to find compatible libraries

media-libs/rubberband fails to find compatible libraries

View unanswered posts
View posts from last 24 hours

Gentoo Forums Forum Index

Portage & Programming

View previous topic :: View next topic

Author

Message

elsandosgrande
Tux's lil' helper

Joined: 18 May 2019
Posts: 144
Location: Sarajevo 71000, Bosnia and Herzegovina

Posted: Sun Jul 21, 2019 3:16 pm Post subject: media-libs/rubberband fails to find compatible libraries

When emerging the package mentioned above, the compilation fails due to not being able to find the required libraries in /usr/lib. This is understandable, as I am running the 17.1 profile.

Code:

***

g++ -shared -Wl,-Bsymbolic -Wl,--version-script=vamp/vamp-plugin.map -o lib/vamp-rubberband.so src/rubberband-c.o src/RubberBandStretcher.o src/StretcherProcess.o src/StretchCalculator.o src/base/Profiler.o src/dsp/AudioCurveCalculator.o src/audiocurves/CompoundAudioCurve.o src/audiocurves/SpectralDifferenceAudioCurve.o src/audiocurves/HighFrequencyAudioCurve.o src/audiocurves/SilentAudioCurve.o src/audiocurves/ConstantAudioCurve.o src/audiocurves/PercussiveAudioCurve.o src/dsp/Resampler.o src/dsp/FFT.o src/system/Allocators.o src/system/sysutils.o src/system/Thread.o src/StretcherChannelData.o src/StretcherImpl.o vamp/RubberBandVampPlugin.o vamp/libmain.o -L/usr/lib -lvamp-sdk -lsamplerate -lfftw3 -O3 -march=bdver4 -pipe -pthread -fopenmp -fira-hoist-pressure -fira-loop-pressure -fdata-sections -ffunction-sections -fbranch-target-load-optimize -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=3 -fuse-linker-plugin -fuse-ld=bfd -Wall -Wextra -Wno-error -Wl,-O1 -Wl,--as-needed -Wl,-O3,--gc-sections,--gc-keep-exported -lpthread -O3 -march=bdver4 -pipe -pthread -fopenmp -fira-hoist-pressure -fira-loop-pressure -fdata-sections -ffunction-sections -fbranch-target-load-optimize -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=3 -fuse-linker-plugin -fuse-ld=bfd -Wall -Wextra -Wno-error -Wl,-O1 -Wl,--as-needed -Wl,-O3,--gc-sections,--gc-keep-exported
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libvamp-sdk.so when searching for -lvamp-sdk
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libvamp-sdk.a when searching for -lvamp-sdk
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libsamplerate.so when searching for -lsamplerate
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libfftw3.so when searching for -lfftw3
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libm.a when searching for -lm
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libc.a when searching for -lc
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.gentoo.org/> for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [Makefile:159: lib/vamp-rubberband.so] Error 1
make: *** Waiting for unfinished jobs....

***

Full output: https://gist.github.com/elsandosgrande/282fc981fa22d89e647024064e926df3

Code:

root@sandys-pavilion:/home/sandy# cat /etc/portage/make.conf
# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.
NTHREADS="3"
source /etc/portage/make.conf.lto.defines
CHOST="x86_64-pc-linux-gnu"
COMMON_FLAGS="-O3 -march=bdver4 -pipe -pthread -fopenmp -fira-hoist-pressure -fira-loop-pressure -fdata-sections -ffunction-sections -fbranch-target-load-optimize ${GRAPHITE} ${DEVIRTLTO} ${IPAPTA} ${SEMINTERPOS} ${FLTO} -fuse-linker-plugin -fuse-ld=bfd -Wall -Wextra -Wno-error"
#COMMON_FLAGS="-O3 -march=bdver4 -pipe -pthread -fgraphite-identity -floop-nest-optimize ${DEVIRTLTO} ${IPAPTA} ${SEMINTERPOS} ${NOPLT} ${FLTO} -fuse-linker-plugin -fuse-ld=bfd -Wall -Wextra -Wno-error"
LOG="trace"
CC="gcc"
CXX="g++"
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="${COMMON_FLAGS}"
FFLAGS="${COMMON_FLAGS}"
LDFLAGS="${COMMON_FLAGS} ${LDFLAGS} -Wl,-O3,--gc-sections,--gc-keep-exported"
CPU_FLAGS_X86="fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good acc_power nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 sse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm perfctr_core perfctr_nb bpext ptsc mwaitx cpb hw_pstate ssbd vmmcall fsgsbase bmi1 avx2 smep bmi2 xsaveopt arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov"
MAKEOPTS="-j${NTHREADS}"
VIDEO_CARDS="amdgpu radeonsi radeon"
INPUT_DEVICES="libinput wacom"
PYTHON_TARGETS="python3_7 python3_6 python2_7"
ABI_X86="32 64"
GRUB_PLATFORMS="efi-64"
#FEATURES="buildpkg"
USE="* -selinux -sesandbox -minimal -static-libs -static -doc -nsplugin -webkit -bindist -classic -javamail -xa -xvmc uuid gmp modern-top numa wireshark-plugins aio ptex context numpy opencv dbus virt-network amr amrenc cdio rubberband libaom libdrm frei0r kdenlive user-permissions caps scanner colord speex imagemagick gps webengine drm libkms brightness-control mem-scramble tls-heartbeat asm hpn cracklib lensfun vala umfpack cholmod gsl raw color-management openexr qtmedia heif eps cjk hardened pch pie lto androiddump ciscodump libxml2 nghttp2 sbc smi clamdtop gnuefi sasl cxx examples corefonts scripts extras yaml fuse iso lz4 dri3 gallium gbm vulkan-overlay -gccgo id3tag sbsms ftp graphite prison fcitx4 fcitx mousepad appstream lzma sha3 webp tiff xpm gd orientation gnuplot qalculate xml geolocation lrz rar 7zip tools pci quad mpi fftw cdrom pdfimport cddb projectm vpx fontconfig fluidsynth libass twolame postproc dav1d aribsub taglib musepack shout skins sid omxil nfs zvbi gme joystick touchpad pam threads user-session gpm system-llvm usbredir fdt usb systemtap filecaps sync-plugin-portage apache2 nginx fpm mysqli mysql unicode layers glib minizip fortran openmp bluetooth -vc ldap kde v4l jpeg2k vulkan wallpapers swaybg swaymsg swaynag swaybar man googledrive virgl spice vlc gentoo-vm java kms sqlite sync-plugin-portage gpg git flac bash-completion audiofile aac acpi browser-integration wallpapers grub gtk3 gtk handbook networkmanager vcd vim-syntax usb svg svga plasma posix postscript ogg mtp multilib mp4 mp3 png matroska lm_sensors libcaca latex libinput acl vaapi vdpau opus theora x265 openh264 openimageio cycles llvm ffmpeg gstreamer native-headset sox realtime qt5 qt4 pulseaudio openal opengl opencl wifi connection-sharing icu ssl egl gles3 gles2 gles wayland sound video X symlink python mount"
#POLICY_TYPES="strict targeted"
LLVM_TARGETS="AMDGPU WebAssembly"
ACCEPT_LICENSE="*"
GENTOO_MIRRORS="http://ftp.ntua.gr/pub/linux/gentoo/ https://mirrors.evowise.com/gentoo/ https://ftp.halifax.rwth-aachen.de/gentoo/ http://ftp.halifax.rwth-aachen.de/gentoo/"
# NOTE: This stage was built with the bindist Use flag enabled
PORTDIR="/usr/portage"
DISTDIR="/usr/portage/distfiles"
PKGDIR="/usr/portage/packages"
CONFIG_PROTECT="-* /usr/lib/sysctl.d/90-override.conf /etc/nginx/nginx.conf /etc/systemd/system/"
ACCEPT_KEYWORDS="~amd64"
# This sets the language of build output to English.
# Please keep this setting intact when reporting bugs.
LC_MESSAGES=C

As some of you may have just now realized, I have the GentooLTO overlay enabled on my system (I have actually done a bit of translation work for it, but let us getting back on track here). As a result, I have done quite a bit of scouring the gcc man page. What I noticed was that the -L/usr/lib flag was used by rubberband during compilation, which completely omitted the lib64 directory.

My question here is: "How does one modify the GCC flags which are out of reach for package.cflags?"

I specify package.cflags in my question, as I do believe that it is pretty overboard to modify make.conf for a single package, especially when it comes to only one section of one program. Also, I did try to add "-L/usr/lib64 [the libraries above]" in package.cflags/rubberband.conf, but simply appended those flags to the flags from make.conf, which did not help.

Post Scriptum

This is my first post on these forums, so here is hoping that I did not make a major mistake somewhere in here. Also, how does one upload files to the forum?

Hu
Administrator

Joined: 06 Mar 2007
Posts: 21773

Posted: Sun Jul 21, 2019 5:22 pm Post subject: Re: media-libs/rubberband fails to find compatible libraries

elsandosgrande wrote:

This is my first post on these forums, so here is hoping that I did not make a major mistake somewhere in here. Also, how does one upload files to the forum?

Welcome to the forum. You've done a very good job for a first post. The forum does not permit attachments to be uploaded. You can paste small bits inline, as you did above, or you can put the file on a pastebin and link to it. We encourage that for larger files, and the forum enforces a maximum post length of ~64KB. That's very generous for written posts, but can be exhausted rapidly by trying to post logs inline.

elsandosgrande wrote:

When emerging the package mentioned above, the compilation fails due to not being able to find the required libraries in /usr/lib. This is understandable, as I am running the 17.1 profile.

Barring user error in the migration, this package should be able to find its libraries. If it's still looking in /usr/lib, then either you skipped a step or the package is buggy. This is not intended as a criticism of you. We've had a lot of people encounter glitches with the migration.

Looking at the error output, I disagree with your diagnosis. There are some warnings about skipped libraries, but the failure is that the linker crashed. That's concerning.

elsandosgrande wrote:

Code:

root@sandys-pavilion:/home/sandy# cat /etc/portage/make.conf
COMMON_FLAGS="-O3 -march=bdver4 -pipe -pthread -fopenmp -fira-hoist-pressure -fira-loop-pressure -fdata-sections -ffunction-sections -fbranch-target-load-optimize ${GRAPHITE} ${DEVIRTLTO} ${IPAPTA} ${SEMINTERPOS} ${FLTO} -fuse-linker-plugin -fuse-ld=bfd -Wall -Wextra -Wno-error"

That is a fairly aggressive set of CFLAGS. Are you sure this did not miscompile your linker?

elsandosgrande wrote:

Code:

CONFIG_PROTECT="-* /usr/lib/sysctl.d/90-override.conf /etc/nginx/nginx.conf /etc/systemd/system/"

You probably don't actually want to abandon CONFIG_PROTECT on all the default files, unless your system has minimal customizations.

elsandosgrande wrote:

What I noticed was that the -L/usr/lib flag was used by rubberband during compilation, which completely omitted the lib64 directory.

It probably got that from pkg-config output of some dependent package. That dependent package may need to be rebuilt to fix its pkg-config file. We've seen quite a number of such failures with migrations to 17.1.

elsandosgrande wrote:

My question here is: "How does one modify the GCC flags which are out of reach for package.cflags?"

I don't know, but I would counter that the package should not require you to make such modifications. The build should find what it needs on its own.

elsandosgrande
Tux's lil' helper

Joined: 18 May 2019
Posts: 144
Location: Sarajevo 71000, Bosnia and Herzegovina

Posted: Sun Jul 21, 2019 6:00 pm Post subject:

Quote:

You've done a very good job for a first post.

Thank you! I honestly thought that I did not, since I omitted emerge --info output.

Quote:

The forum does not permit attachments to be uploaded.

I did make note of the lack of any kind of upload button. I am sad that it is so, but I guess that I will get a lot of practice with GitHub Gists from now on, so...

Quote:

You can paste small bits inline, as you did above, or you can put the file on a pastebin and link to it. We encourage that for larger files, and the forum enforces a maximum post length of ~64KB. That's very generous for written posts, but can be exhausted rapidly by trying to post logs inline.

I did notice that it failed when I tried to share the entire output log in the post. Duly noted.

Quote:

So, how may I check for any such issues, whether they be due to to user error or coding error? To note, I have been running the profile ever since the news reported it as stable (at least stable enough).

Quote:

Looking at the error output, I disagree with your diagnosis. There are some warnings about skipped libraries, but the failure is that the linker crashed. That's concerning.

I did make note of the crash, but, considering that I have compiled over two hundred packages with make.conf as posted above (I have been fighting with LibreOffice and LTO for two weeks, so I am severely behind on updates) and that the skipped libraries include vamp-sdk, which, as I understand, is crucial for the package, my suspicions were on the libraries. I will try switching to ld.gold to see if that helps (it did with Blender, so fingers crossed). If it does not, I will try messing around with the *FLAGS, but I am still under the impression that it is, at least in part, due to the skipped libraries. I will add here that I added ABI_X86_32 before the update, that is, after I figured out that -fsemantic-interposition was what LibreOffice wanted. Maybe that is the issue???

Quote:

That is a fairly aggressive set of CFLAGS. Are you sure this did not miscompile your linker?

I am not sure what you mean by "recompile your linker". If it is a part of the GCC package, then no, though I have neither overridden flag-o-matic (flag stripping), nor ever used BOOT_CFLAGS, so I am not sure what good that might do.

Quote:

You probably don't actually want to abandon CONFIG_PROTECT on all the default files, unless your system has minimal customizations.

Actually, it was "-*" until I actually got around to working on nginx (learning web development), so I have taken all modified files into consideration.

Quote:

Pardon me for asking that which is probably a beginner question, but how may I deduce which package(s) I might need to rebuild? To note, I have emerged "@system --exclude gcc" just before the update, so everything should be fine on that front.

Quote:

I don't know, but I would counter that the package should not require you to make such modifications. The build should find what it needs on its own.

That is obvious, but it is just a matter of time when such an issue might crop up. At that point in time, it might aid in "simple" troubleshooting to be able to modify such flags without modifying ebuilds and the like. Considering the rarity of such an issue, my guess would be that the method is either obscure or non-existent.

Thank you for your time and have a nice day/good night/morning! (I live in Bosnia, so I am used to greatly varying schedules across communities and members of those communities.)

Hu
Administrator

Joined: 06 Mar 2007
Posts: 21773

Posted: Sun Jul 21, 2019 7:26 pm Post subject:

elsandosgrande wrote:

Quote:

You've done a very good job for a first post.

Thank you! I honestly thought that I did not, since I omitted emerge --info output.

So you did. You provided make.conf which, while not quite as good, is close enough in some cases.

elsandosgrande wrote:

Quote:

The forum does not permit attachments to be uploaded.

I did make note of the lack of any kind of upload button. I am sad that it is so, but I guess that I will get a lot of practice with GitHub Gists from now on, so...

You could also use the anonymous pastebin services. If you do this frequently, look at app-misc/wgetpaste, which lets you upload selected files directly from the command line.

elsandosgrande wrote:

Quote:

So, how may I check for any such issues, whether they be due to to user error or coding error?

If you can't solve it yourself, post in the forums. Once we solve it together, we'll know whether it was user error or package error. As for this specific error, I address that a bit farther down.

elsandosgrande wrote:

Quote:

Looking at the error output, I disagree with your diagnosis. There are some warnings about skipped libraries, but the failure is that the linker crashed. That's concerning.

In my opinion, it is always a bug if a program dies of segmentation fault. The only question is whether the bug is in the program itself, or in a tool that built the program in an invalid way. It could be that the missing libraries triggered a latent bug in your ld.bfd and that, without triggering that bug, the linker would have succeeded. Even so, the linker should not crash due to the missing libraries. It should gracefully exit with an error explaining why it cannot succeed.

elsandosgrande wrote:

after I figured out that -fsemantic-interposition was what LibreOffice wanted. Maybe that is the issue???

If LibreOffice required you to set that flag, then LibreOffice is broken. If it needs the flag, it should have set the flag for itself, without involving you. Reading the description of that flag, I can't decide whether it could be relevant here.

elsandosgrande wrote:

Quote:

That is a fairly aggressive set of CFLAGS. Are you sure this did not miscompile your linker?

miscompile (that is, compile in an incorrect way), not recompile. Some flags are known to break some programs. I don't know the full list of what flags cause breakage or what programs are broken by them, but as you add more flags, especially flags from certain subgroups, you increase the risk that you will get a broken program at the end.

elsandosgrande wrote:

Quote:

I would start with whichever package(s) provide the libraries that are not being found. If that doesn't help, you will need to look through the output and logs of the failed build to see where it obtained that flag. Some builds don't actually print what they find, which will make that harder.

elsandosgrande
Tux's lil' helper

Joined: 18 May 2019
Posts: 144
Location: Sarajevo 71000, Bosnia and Herzegovina

Posted: Sun Jul 21, 2019 11:27 pm Post subject:

Quote:

You could also use the anonymous pastebin services.

Considering that I have, at times, come across such anonymous posts without them linking to the relevant bug(s)/report(s), especially when they had the same or similar output to what I was looking for, I think that it is better that I stick to Gists in that regard, as I already have a GitHub account, therefore I can edit the description to include the post it is for, and, in my opinion at least, GitHub Gists are aesthetically superior to Pastebin and the like. (Side note: Why does literally every single phpBB forum that I have found for Linux have this, at least in my opinion, archaic theme? Even the emoticons appear archaic, as if they are bitmaps, though some are animated, so not exactly bitmaps. Why do some forums keep this "look", while others, like the Linus Tech Tips and Level1Techs forums have more modern appearances? Even reddit went through a redesign, though they did not eliminate the older design.)

Quote:

If you can't solve it yourself, post in the forums.

Considering some of the replies to some of the posts on the Arch forums that I have seen, please do pardon me for my reluctance to do so, as I feel like the communities surrounding Linux distributions, barring the vocal minorities that ruin it for everybody, do scale up the minimum "difficulty" of permitted queries (permitted, as in without, and I quote, "go RTFM!" and the like) with the minimum difficulty of the vanilla installation and maintenance.

Quote:

In my opinion, it is always a bug if a program dies of segmentation fault.

Yes, that did seem rather peculiar at the very least. Who knows, I might become the "exotic GCC configurations" debugger at this rate.

Quote:

The only question is whether the bug is in the program itself, or in a tool that built the program in an invalid way.

Well, assuming that my understanding of exactly what constitutes the GCC compiler collection is reasonably sound (id est, ld.bfd is part of the GCC package), that is not really possible, as I had built the GCC package before I heard any mention of GentooLTO, so my flags were "-O2 -march=bdver4 -pipe". (Side note: The further I type, the more I feel like this belongs to "Kernel & Programming", or whatever the section is called. I do not really frequent these forums, so my recollection of such things is not the best.)

Quote:

If LibreOffice required you to set that flag, then LibreOffice is broken.

For brevity's sake, I shall link you to the ticket on GentooLTO in which I explain what is wrong here: https://github.com/InBetweenNames/gentooLTO/issues/382
Also, to make things clearer, look at my make.conf and then look at this file (it is sourced in the aforementioned file): https://github.com/InBetweenNames/gentooLTO/blob/master/sys-config/ltoize/files/make.conf.lto.defines

Quote:

miscompile (that is, compile in an incorrect way), not recompile.

Sorry, my bad.

Quote:

Some flags are known to break some programs. I don't know the full list of what flags cause breakage or what programs are broken by them, but as you add more flags, especially flags from certain subgroups, you increase the risk that you will get a broken program at the end.

I understand the risks, especially with the flags that I added manually. Even so:

Mesa works just fine after being compiled with -O3 and the like, even though I found somewhere that Mesa will be broken if compiled with -O3. There was no mention of LTO, so that must have been out of the question in the mind of that writer at that point in time.
If it were some major issue with the flags, issues would have cropped up much sooner than package two-hundred and some change, especially since things like systemd got emerged before rubberband.

Quote:

I would start with whichever package(s) provide the libraries that are not being found.

Considering that I do not know how to find pkgfile through emerge --search and this is not Arch, how would I go about finding the packages in question? Also, vamp-sdk (one of the packages which got emerged before rubberband in the same list and most likely provides the library which shares its name) was emerged beforehand and everything looked peachy, so...

Quote:

If that doesn't help, you will need to look through the output and logs of the failed build to see where it obtained that flag. Some builds don't actually print what they find, which will make that harder.

When I was going over the preview of my first post, before I realized that some of the text had to go, I found a line in which it said "--libdir /usr/lib" without listing /usr/lib64, so...

Sorry that I am not doing much more testing. My mother broke her leg (I am 17, by the way), so it has been a bit tiring these past two weeks. Anyway, I am off to eat and go to bed now (it is 1:24h right now here in Sarajevo), so we shall type to each other, I guess (it is always weird when I try to adapt a common phrase to a different environment or medium), later. Have a good night/...!

Edit
I only noticed that I had not properly configured the ordered list after posting.

elsandosgrande
Tux's lil' helper

Joined: 18 May 2019
Posts: 144
Location: Sarajevo 71000, Bosnia and Herzegovina

Posted: Mon Jul 22, 2019 1:25 pm Post subject:

So, switching to gold (-fuse-ld=gold) results in the configuration failing with: "checking whether the C++ compiler works... no".

Also, the line following states: "configure: error: in `/var/tmp/portage/media-libs/rubberband-1.8.2/work/rubberband-1.8.2-abi_x86_32.x86'"
abi_x86_32.x86
Perhaps it is that I need to find the packages that are providing those libraries and see what is going wrong, just as you suggested Hu.

Edit (22.7.2019. 23:10h)

So... After I removed "-flto=3 -fuse-linker-plugin", I got this:

Code:

***

g++ -shared -Wl,-Bsymbolic -Wl,--version-script=ladspa/ladspa-plugin.map -o lib/ladspa-rubberband.so src/rubberband-c.o src/RubberBandStretcher.o src/StretcherProcess.o src/StretchCalculator.o src/base/Profiler.o src/dsp/AudioCurveCalculator.o src/audiocurves/CompoundAudioCurve.o src/audiocurves/SpectralDifferenceAudioCurve.o src/audiocurves/HighFrequencyAudioCurve.o src/audiocurves/SilentAudioCurve.o src/audiocurves/ConstantAudioCurve.o src/audiocurves/PercussiveAudioCurve.o src/dsp/Resampler.o src/dsp/FFT.o src/system/Allocators.o src/system/sysutils.o src/system/Thread.o src/StretcherChannelData.o src/StretcherImpl.o ladspa/RubberBandPitchShifter.o ladspa/libmain.o -lsamplerate -lfftw3 -O3 -march=bdver4 -pipe -pthread -fopenmp -fira-hoist-pressure -fira-loop-pressure -fdata-sections -ffunction-sections -fbranch-target-load-optimize -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -fuse-ld=bfd -Wall -Wextra -Wno-error -Wl,-O1 -Wl,--as-needed -Wl,-O3 -Wl,--gc-keep-exported -Wl,--gc-sections -lpthread -O3 -march=bdver4 -pipe -pthread -fopenmp -fira-hoist-pressure -fira-loop-pressure -fdata-sections -ffunction-sections -fbranch-target-load-optimize -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -fuse-ld=bfd -Wall -Wextra -Wno-error -Wl,-O1 -Wl,--as-needed -Wl,-O3 -Wl,--gc-keep-exported -Wl,--gc-sections
g++ -shared -Wl,-Bsymbolic -Wl,--version-script=vamp/vamp-plugin.map -o lib/vamp-rubberband.so src/rubberband-c.o src/RubberBandStretcher.o src/StretcherProcess.o src/StretchCalculator.o src/base/Profiler.o src/dsp/AudioCurveCalculator.o src/audiocurves/CompoundAudioCurve.o src/audiocurves/SpectralDifferenceAudioCurve.o src/audiocurves/HighFrequencyAudioCurve.o src/audiocurves/SilentAudioCurve.o src/audiocurves/ConstantAudioCurve.o src/audiocurves/PercussiveAudioCurve.o src/dsp/Resampler.o src/dsp/FFT.o src/system/Allocators.o src/system/sysutils.o src/system/Thread.o src/StretcherChannelData.o src/StretcherImpl.o vamp/RubberBandVampPlugin.o vamp/libmain.o -L/usr/lib -lvamp-sdk -lsamplerate -lfftw3 -O3 -march=bdver4 -pipe -pthread -fopenmp -fira-hoist-pressure -fira-loop-pressure -fdata-sections -ffunction-sections -fbranch-target-load-optimize -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -fuse-ld=bfd -Wall -Wextra -Wno-error -Wl,-O1 -Wl,--as-needed -Wl,-O3 -Wl,--gc-keep-exported -Wl,--gc-sections -lpthread -O3 -march=bdver4 -pipe -pthread -fopenmp -fira-hoist-pressure -fira-loop-pressure -fdata-sections -ffunction-sections -fbranch-target-load-optimize -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -fuse-ld=bfd -Wall -Wextra -Wno-error -Wl,-O1 -Wl,--as-needed -Wl,-O3 -Wl,--gc-keep-exported -Wl,--gc-sections
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libvamp-sdk.so when searching for -lvamp-sdk
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libvamp-sdk.a when searching for -lvamp-sdk
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libsamplerate.so when searching for -lsamplerate
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libfftw3.so when searching for -lfftw3
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libm.a when searching for -lm
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: skipping incompatible /usr/lib/libc.a when searching for -lc
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: i386 architecture of input file `/var/tmp/portage/media-libs/rubberband-1.8.2/temp/vamp-rubberband.so.gDN8Du.ltrans0.ltrans.o' is incompatible with i386:x86-64 output
collect2: error: ld returned 1 exit status
make: *** [Makefile:159: lib/vamp-rubberband.so] Error 1
* ERROR: media-libs/rubberband-1.8.2::gentoo failed (compile phase):
* emake failed
*
* If you need support, post the output of `emerge --info '=media-libs/rubberband-1.8.2::gentoo'`,
* the complete build log and the output of `emerge -pqv '=media-libs/rubberband-1.8.2::gentoo'`.
* The complete build log is located at '/var/tmp/portage/media-libs/rubberband-1.8.2/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/media-libs/rubberband-1.8.2/temp/environment'.
* Working directory: '/var/tmp/portage/media-libs/rubberband-1.8.2/work/rubberband-1.8.2-abi_x86_64.amd64'
* S: '/var/tmp/portage/media-libs/rubberband-1.8.2/work/rubberband-1.8.2'

>>> Failed to emerge media-libs/rubberband-1.8.2, Log file:

>>> '/var/tmp/portage/media-libs/rubberband-1.8.2/temp/build.log'

* Messages for package media-libs/rubberband-1.8.2:

* ERROR: media-libs/rubberband-1.8.2::gentoo failed (compile phase):
* emake failed
*
* If you need support, post the output of `emerge --info '=media-libs/rubberband-1.8.2::gentoo'`,
* the complete build log and the output of `emerge -pqv '=media-libs/rubberband-1.8.2::gentoo'`.
* The complete build log is located at '/var/tmp/portage/media-libs/rubberband-1.8.2/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/media-libs/rubberband-1.8.2/temp/environment'.
* Working directory: '/var/tmp/portage/media-libs/rubberband-1.8.2/work/rubberband-1.8.2-abi_x86_64.amd64'
* S: '/var/tmp/portage/media-libs/rubberband-1.8.2/work/rubberband-1.8.2'

i386 architecture of input file `/var/tmp/portage/media-libs/rubberband-1.8.2/temp/vamp-rubberband.so.gDN8Du.ltrans0.ltrans.o' is incompatible with i386:x86-64 output

Forget the aggressive flags, I think that we might have an ABI issue.

Code:

[ebuild R ] media-libs/rubberband-1.8.2::gentoo USE="-static-libs" ABI_X86="32* (64) -x32" 0 KiB

Hu
Administrator

Joined: 06 Mar 2007
Posts: 21773

Posted: Tue Jul 23, 2019 1:50 am Post subject:

elsandosgrande wrote:

As you wish. Most pastebin services expire within a few weeks, so you wouldn't tend to come across severely outdated pastes. However, if you intend to leave the paste up, it makes sense to link it to the forum.

elsandosgrande wrote:

(Side note: Why does literally every single phpBB forum that I have found for Linux have this, at least in my opinion, archaic theme? Even the emoticons appear archaic, as if they are bitmaps, though some are animated, so not exactly bitmaps. Why do some forums keep this "look", while others, like the Linus Tech Tips and Level1Techs forums have more modern appearances? Even reddit went through a redesign, though they did not eliminate the older design.)

I can't speak to other forums, but in the case of the Gentoo forums, there has not been a sufficiently compelling reason to force an upgrade of the underlying software, and it dates from a time when aesthetics and implementation tended to be intermingled. I suspect the appearance cannot be changed substantially without modifying the software. Moreover, I happen to like how this place looks, so if I were the responsible party, I'd probably try to keep the appearance even if I upgraded the software.

elsandosgrande wrote:

Hu wrote:

If you can't solve it yourself, post in the forums.

Yes, some forums are rather hostile. I like to think that we are not. Look at the quantity and content of posts from our regulars (not just the moderators, but the well recognized private contributors).

elsandosgrande wrote:

Hu wrote:

The only question is whether the bug is in the program itself, or in a tool that built the program in an invalid way.

Understood. I thought you had built all components with the more aggressive flags you showed. If the core was built with well-tested flags, then it seems much less likely that the core has been broken by compiler mischief.

elsandosgrande wrote:

(Side note: The further I type, the more I feel like this belongs to "Kernel & Programming", or whatever the section is called. I do not really frequent these forums, so my recollection of such things is not the best.)

We have Kernel&Hardware and Portage&Programming. If you feel your thread is in the wrong place, you can use the Report button to request it to be moved.

elsandosgrande wrote:

Hu wrote:

If LibreOffice required you to set that flag, then LibreOffice is broken.

Reading through that, it looks like you forced everything to -fno-semantic-interposition, then found that LibreOffice handled that poorly. If the default is -fsemantic-interposition, and LibreOffice requires that default, I am inclined to withdraw my prior statement. I think it is not reasonable to expect LibreOffice to detect and countermand every non-default compiler flag that can break it. When I wrote above, I was of the misunderstanding that LibreOffice was broken by default on a very bland setup. If you start setting unusual compiler flags, it's your responsibility not to break things.

elsandosgrande wrote:

I understand the risks, especially with the flags that I added manually. Even so:

Mesa works just fine after being compiled with -O3 and the like, even though I found somewhere that Mesa will be broken if compiled with -O3. There was no mention of LTO, so that must have been out of the question in the mind of that writer at that point in time.

Perhaps older versions were broken, and the code has since been changed. It could also be that -O3 enabled some flag which was implemented incorrectly, and a newer gcc version corrected the implementation, so -O3 would be unsafe with an old version of gcc, but fine now.

elsandosgrande wrote:

Hu wrote:

I would start with whichever package(s) provide the libraries that are not being found.

Considering that I do not know how to find pkgfile through emerge --search and this is not Arch, how would I go about finding the packages in question?

equery belongs /path/to/file

elsandosgrande wrote:

Also, vamp-sdk (one of the packages which got emerged before rubberband in the same list and most likely provides the library which shares its name) was emerged beforehand and everything looked peachy, so...

That is interesting. What is the output of equery files vamp-sdk ; pkg-config --libs vamp-sdk? You may need to adjust the argument to pkg-config, depending on the name of the .pc file installed by vamp-sdk. It may even not install one at all, if everything goes into a default search directory.

elsandosgrande wrote:

Sorry that I am not doing much more testing.

Part of the value of the forums is to provide guidance so you know what to test. It'd be a waste of time for you to test the wrong things because you don't know what to test, so it is worthwhile to seek help here so that when you test, you focus on things that are likely to be useful.

elsandosgrande wrote:

My mother broke her leg (I am 17, by the way), so it has been a bit tiring these past two weeks. Anyway, I am off to eat and go to bed now (it is 1:24h right now here in Sarajevo), so we shall type to each other, I guess (it is always weird when I try to adapt a common phrase to a different environment or medium), later. Have a good night/...!

Sorry to hear that. Take care of her, and of yourself, before Gentoo. We'll be here when she has recovered and you have more free time.

elsandosgrande
Tux's lil' helper

Joined: 18 May 2019
Posts: 144
Location: Sarajevo 71000, Bosnia and Herzegovina

Posted: Tue Jul 23, 2019 4:44 pm Post subject:

Quote:

Code:

root@sandys-pavilion:/home/sandy# equery files vamp-plugin-sdk
* Searching for vamp-plugin-sdk ...
* Contents of media-libs/vamp-plugin-sdk-2.7.1:
/usr
/usr/bin
/usr/bin/vamp-rdf-template-generator
/usr/bin/vamp-simple-host
/usr/include
/usr/include/vamp
/usr/include/vamp-hostsdk
/usr/include/vamp-hostsdk/Plugin.h
/usr/include/vamp-hostsdk/PluginBase.h
/usr/include/vamp-hostsdk/PluginBufferingAdapter.h
/usr/include/vamp-hostsdk/PluginChannelAdapter.h
/usr/include/vamp-hostsdk/PluginHostAdapter.h
/usr/include/vamp-hostsdk/PluginInputDomainAdapter.h
/usr/include/vamp-hostsdk/PluginLoader.h
/usr/include/vamp-hostsdk/PluginSummarisingAdapter.h
/usr/include/vamp-hostsdk/PluginWrapper.h
/usr/include/vamp-hostsdk/RealTime.h
/usr/include/vamp-hostsdk/host-c.h
/usr/include/vamp-hostsdk/hostguard.h
/usr/include/vamp-hostsdk/vamp-hostsdk.h
/usr/include/vamp-sdk
/usr/include/vamp-sdk/FFT.h
/usr/include/vamp-sdk/Plugin.h
/usr/include/vamp-sdk/PluginAdapter.h
/usr/include/vamp-sdk/PluginBase.h
/usr/include/vamp-sdk/RealTime.h
/usr/include/vamp-sdk/plugguard.h
/usr/include/vamp-sdk/vamp-sdk.h
/usr/include/vamp/vamp.h
/usr/lib
/usr/lib/libvamp-hostsdk.a
/usr/lib/libvamp-hostsdk.la
/usr/lib/libvamp-hostsdk.so -> libvamp-hostsdk.so.3.7.0
/usr/lib/libvamp-hostsdk.so.3 -> libvamp-hostsdk.so.3.7.0
/usr/lib/libvamp-hostsdk.so.3.7.0
/usr/lib/libvamp-sdk.a
/usr/lib/libvamp-sdk.la
/usr/lib/libvamp-sdk.so -> libvamp-sdk.so.2.7.0
/usr/lib/libvamp-sdk.so.2 -> libvamp-sdk.so.2.7.0
/usr/lib/libvamp-sdk.so.2.7.0
/usr/lib/pkgconfig
/usr/lib/pkgconfig/vamp-hostsdk.pc
/usr/lib/pkgconfig/vamp-sdk.pc
/usr/lib/pkgconfig/vamp.pc
/usr/lib/vamp
/usr/lib/vamp/vamp-example-plugins.cat
/usr/lib/vamp/vamp-example-plugins.n3
/usr/lib/vamp/vamp-example-plugins.so
/usr/lib64
/usr/lib64/libvamp-hostsdk.a
/usr/lib64/libvamp-hostsdk.la
/usr/lib64/libvamp-hostsdk.so -> libvamp-hostsdk.so.3.7.0
/usr/lib64/libvamp-hostsdk.so.3 -> libvamp-hostsdk.so.3.7.0
/usr/lib64/libvamp-hostsdk.so.3.7.0
/usr/lib64/libvamp-sdk.a
/usr/lib64/libvamp-sdk.la
/usr/lib64/libvamp-sdk.so -> libvamp-sdk.so.2.7.0
/usr/lib64/libvamp-sdk.so.2 -> libvamp-sdk.so.2.7.0
/usr/lib64/libvamp-sdk.so.2.7.0
/usr/lib64/pkgconfig
/usr/lib64/pkgconfig/vamp-hostsdk.pc
/usr/lib64/pkgconfig/vamp-sdk.pc
/usr/lib64/pkgconfig/vamp.pc
/usr/lib64/vamp
/usr/lib64/vamp/vamp-example-plugins.cat
/usr/lib64/vamp/vamp-example-plugins.n3
/usr/lib64/vamp/vamp-example-plugins.so
/usr/share
/usr/share/doc
/usr/share/doc/vamp-plugin-sdk-2.7.1
/usr/share/doc/vamp-plugin-sdk-2.7.1/CHANGELOG.bz2
/usr/share/doc/vamp-plugin-sdk-2.7.1/README.bz2
/usr/share/doc/vamp-plugin-sdk-2.7.1/README.compat.bz2
root@sandys-pavilion:/home/sandy# pkg-config --libs vamp-plugins-sdk
Package vamp-plugins-sdk was not found in the pkg-config search path.
Perhaps you should add the directory containing `vamp-plugins-sdk.pc'
to the PKG_CONFIG_PATH environment variable
Package 'vamp-plugins-sdk', required by 'virtual:world', not found
root@sandys-pavilion:/home/sandy# pkg-config --libs vamp-sdk
-L/usr/lib -lvamp-sdk
root@sandys-pavilion:/home/sandy# pkg-config --libs vamp

root@sandys-pavilion:/home/sandy# pkg-config --libs vamp-hostsdk
-L/usr/lib -lvamp-hostsdk -ldl

So, even though vamp-plugins-sdk installs its libraries where it should, the pc file only lists /usr/lib. Terrific! Also:

Quote:

i386 architecture of input file `/var/tmp/portage/media-libs/rubberband-1.8.2/temp/vamp-rubberband.so.gDN8Du.ltrans0.ltrans.o' is incompatible with i386:x86-64 output

This is in the edit of my previous post.

Quote:

If you start setting unusual compiler flags, it's your responsibility not to break things.

That is what https://github.com/InBetweenNames/gentooLTO/blob/master/sys-config/ltoize/files/package.cflags/ltoworkarounds.conf is for.

Quote:

I figured that the information was outdated. (Side note: Considering that most of the more important packages, GCC, glibc and the like, strip flags anyway, I think that, as GCC matures further and code quality of packages improves on average, we might be able to recommend -O3 instead of -O2 soon.)

Quote:

equery belongs /path/to/file

Somebody should mention that on the Portage wiki page. Seriously. I know it is not a part of Portage, but it should be mentioned somehow, maybe in a banner, like the warnings and notes that are spread all acoss the wiki.

Quote:

Considering that only the pasted content contains the exact phrase one might theoretically search for if they have the same problem as me, or at least a problem that is somehow related to mine ("exact line from error output here"; that is what I always try alongside a few other things), I do wish to have things present permanently. That, and I would imagine that it would seriously burn if somebody were to come across this for whatever reason, take interest in it for whatever reason and then find that the links have long since expired.

Quote:

Fair enough. Wait, in that case, what does this forum run on?

Quote:

I suspect the appearance cannot be changed substantially without modifying the software. Moreover, I happen to like how this place looks, so if I were the responsible party, I'd probably try to keep the appearance even if I upgraded the software.

Understandable, but, if things got an upgrade, the appearance could be handled like on reddit, both old and new available at one's fingertips.

Quote:

I have indeed noticed that this is much more laid-back than Arch. I guess you cannot simply say "go RTFM!" when every system is more or less unique, whether it be in terms of USE flags, GCC flags, or even both, not to even mention installed packages and overlays, though the last point is not too dissimilar from PPAs in my experience, at least when it comes to package management.

Quote:

Even if I had GentooLTO present on my laptop at the time that I built GCC, it would have still stripped most of the flags, so I would either end up with "-O3 -march=bdver4 -pipe" or "-march=bdver4 -pipe". With that said, some people who were darring enough to overried flag-o-matic and modify BOOT_CFLAGS have reported that there were weird compilation and runtime issues after building GCC with said modifications. For now, I am not darring enough to try something that will almost certainly end in disaster.

Quote:

We have Kernel&Hardware and Portage&Programming. If you feel your thread is in the wrong place, you can use the Report button to request it to be moved.

Well, here we go then.

Quote:

Good point, though I am not sure that many people would have said that Blender would succeed building with ld.gold as opposed to ld.bfd with that combination of USE and GCC flags (https://github.com/InBetweenNames/gentooLTO/issues/381 is what I am referring to; it was just a wacky thought that I had, but it actually worked, go figure). Still, when encountering not-so-exotic issues, I think that I will actually ask around instead of staring at DuckDuckGo for a few days until I get a breakthrough.

Quote:

Sorry to hear that. Take care of her, and of yourself, before Gentoo. We'll be here when she has recovered and you have more free time.

Two months before the cast comes off + however long physical therapy wil take = my system will completely break down mid-way through the updates if several months of them pile up. Sadly, this is not an ideal world.
At risk of making this appear as a plug, you could watch my recent video (https://youtu.be/WoROyGCzAyM) if you are curious about what happened, though that is only one part of the video, id est, the video is not focused on that topic, or any particular topic for that matter. Alternatively, I did talk about it in the GentooLTO Gitter channel, or whatever it is called, as well. If it is not cocher to link to the video, I shall promptly remove it after you respond (or anybody else who voices concern for that matter).

Edit

Here's something strange:

Code:

root@sandys-pavilion:/home/sandy# pkg-config --libs /usr/lib64/pkgconfig/vamp-sdk.pc
-L/usr/lib -lvamp-sdk

I do not think that that is how it should be.

Hu
Administrator

Joined: 06 Mar 2007
Posts: 21773

Posted: Wed Jul 24, 2019 2:40 am Post subject:

elsandosgrande wrote:

So, even though vamp-plugins-sdk installs its libraries where it should, the pc file only lists /usr/lib. Terrific!

This is probably not hard to fix. However, it looks to me like it installed its libraries in both places, which seems wrong.

elsandosgrande wrote:

Fair enough. Wait, in that case, what does this forum run on?

An old version of phpBB.

elsandosgrande wrote:

Understandable, but, if things got an upgrade, the appearance could be handled like on reddit, both old and new available at one's fingertips.

That would probably be available, yes.

elsandosgrande wrote:

Alternatively, I did talk about it in the GentooLTO Gitter channel, or whatever it is called, as well. If it is not cocher to link to the video, I shall promptly remove it after you respond (or anybody else who voices concern for that matter).

I think a brief mention like this is fine.

elsandosgrande
Tux's lil' helper

Joined: 18 May 2019
Posts: 144
Location: Sarajevo 71000, Bosnia and Herzegovina

Posted: Wed Jul 24, 2019 11:12 am Post subject:

Hu wrote:

This is probably not hard to fix. However, it looks to me like it installed its libraries in both places, which seems wrong.

Well, it actually is supposed to install both 32 and 64-bit libraries (17.1 profile). Also, I just took a wild guess and, well, it worked!

https://gist.github.com/elsandosgrande/6acc4b20a1852fad30d1cd237275a12f

Code:

root@sandys-pavilion:/home/sandy# cat /usr/lib64/pkgconfig/vamp-sdk.pc
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib64
includedir=${prefix}/include

Name: vamp-sdk
Version: 2.7.1
Description: Development library for Vamp audio analysis plugins
Libs: -L${libdir} -lvamp-sdk
Cflags: -I${includedir}

I edited /usr/lib64/pkgconfig/vamp-sdk.pc to add /usr/lib64 and it worked!!! Should I create a bug linking to this forum post for further details?

Hu wrote:

An old version of phpBB.

I meant: "What OS is it running on?", since the "old version of phpBB" fact was already established.

Hu wrote:

That would probably be available, yes.

Lovely! Also, where could I post a suggestion regarding the forum in general? I think that something like https://www.phpbb.com/customise/db/style/prosilver_mobile/ would be lovely for those using, or at least trying to, their phones, especially feature phones, on the forum.

Hu wrote:

I think a brief mention like this is fine.

Yay!

Thank you so much for your time thus far!

Post Scriptum

I finally figured out how to label quotes. Yay!

dib.gentoo
n00b
n00b

Joined: 29 Oct 2018
Posts: 10

Posted: Wed Jul 24, 2019 7:09 pm Post subject:

I have the exact same problem here: Segfaults with LTO, and once this is disabled, incompatible vamp-sdk lib because of pkg-config. After disabling LTO and fixing /usr/lib64/pkgconfig/vamp-sdk.pc it works fine here. I will file an issue at GentooLTO, but I don't have the time to file a bug report against vamp-sdk right now. Maybe someone else can do this? Anyway, thank you all for the hints to fix it!

elsandosgrande
Tux's lil' helper

Joined: 18 May 2019
Posts: 144
Location: Sarajevo 71000, Bosnia and Herzegovina

Posted: Wed Jul 24, 2019 10:42 pm Post subject:

dib.gentoo wrote:

I have the exact same problem here: Segfaults with LTO, and once this is disabled, incompatible vamp-sdk lib because of pkg-config.

After disabling LTO and fixing /usr/lib64/pkgconfig/vamp-sdk.pc it works fine here.

I will file an issue at GentooLTO, but I don't have the time to file a bug report against vamp-sdk right now. Maybe someone else can do this?

Anyway, thank you all for the hints to fix it!

I am glad that we were of assistance to you! No worries, I will file a bug report if necessary, though I would like moderator input prior to pulling the trigger. Who knows, maybe a developer might pitch in if I'm lucky.

Also, it is not an issue that is related to GentooLTO, as this would affect a vanilla installation as well, though the issue would be more obvious without the segmentation fault masking it.

Hu
Administrator

Joined: 06 Mar 2007
Posts: 21773

Posted: Thu Jul 25, 2019 2:19 am Post subject:

elsandosgrande wrote:

Hu wrote:

This is probably not hard to fix. However, it looks to me like it installed its libraries in both places, which seems wrong.

Well, it actually is supposed to install both 32 and 64-bit libraries (17.1 profile). Also, I just took a wild guess and, well, it worked!

I see. I was thinking that the 17.1 migration had taken the opportunity to have lib32 (x86 libraries), lib (non-code library-like things), and lib64 all be distinct. I re-read the news and see that I misremembered that.

elsandosgrande wrote:

I edited /usr/lib64/pkgconfig/vamp-sdk.pc to add /usr/lib64 and it worked!!! Should I create a bug linking to this forum post for further details?

You should create a bug, but many developers seem to dislike being asked to go read the forum for supporting detail, so if possible, you should make the bug report complete and usable without reference to this thread. If you want to link to the thread for background, that is fine, so long as the bug report itself describes what is wrong and what you want changed.

elsandosgrande wrote:

Hu wrote:

An old version of phpBB.

I meant: "What OS is it running on?", since the "old version of phpBB" fact was already established.

Probably some sort of Gentoo, but I don't know. I never asked, and I don't log in to the systems that run it.

elsandosgrande wrote:

Also, where could I post a suggestion regarding the forum in general? I think that something like https://www.phpbb.com/customise/db/style/prosilver_mobile/ would be lovely for those using, or at least trying to, their phones, especially feature phones, on the forum.

Start in Gentoo Forums Feedback. If that's the wrong place, someone can move it.

elsandosgrande wrote:

I will file a bug report if necessary, though I would like moderator input prior to pulling the trigger. Who knows, maybe a developer might pitch in if I'm lucky.

My status as forum moderator doesn't convey any particular weight to my opinion on when to report bugs. I would like to believe my long history and general Gentoo experience contribute some weight, but I had those before I became a moderator and will still have those even if I step down some day.

You don't need my approval to file a report. If you're uncertain about a given report, you're welcome to ask in the forums for a forum regular (not necessarily a moderator, anyone with a history of providing good advice will do) to advise you on how to proceed.

elsandosgrande
Tux's lil' helper

Joined: 18 May 2019
Posts: 144
Location: Sarajevo 71000, Bosnia and Herzegovina

Posted: Thu Jul 25, 2019 3:34 am Post subject:

Since I am replying from my smartphone, I cannot really quote anything, so please bare with me here. One, I am glad that I did not get something wrong, since I am not really good at recalling many such facts accurately. Two, here is the bug: https://bugs.gentoo.org/690676 (I did give a summary with the exact fix that worked for me, but I still referred to the forum for further detail) Three, I guess that I will ask around then. Thanks nevertheless! Four, since I already pulled the trigger on the bug, here's hoping that they don't burn me as if it were Salem. Any tips for improvements for the next bug? Once again, thank you so much for your time and have a great day!

Display posts from previous:

	Gentoo Forums Forum Index Portage & Programming	All times are GMT
Page 1 of 1

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Copyright 2001-2024 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy