It makes it quite nasty to deal with the way it is now since it does not fall into my whitelist for proprietary software; in /usr I'd expect only code that we built ourselves, what is the reason to have fmod in there rather than /opt?
Yes, you are right, I don't know what I was thinking installing them in /usr I'll try to get into this today.. there's a new release of fmod anyway.
Done
How is one expected to link to it or include its headers now?
- It still symlinks includes to /usr/include/fmodex, this works. - It adds a LDPATH to the libraries using env.d to /etc/ld.so.conf, but I tried with media-sound/bpmdetect and it couldn't link to -lfmodex, this is a problem. Diego, I'm going to move the binary only libraries back to libdir because it simply doesn't work, unless you can expain to me why LDPATH doesn't work when linker is trying to link -lfmodex even if the path is in LDPATH.
media-sound/bpmdetect is a good test subject.
We already had a similar issue with cuda: https://bugs.gentoo.org/show_bug.cgi?id=255839 Yes it does work, and no you're not going to keep prebuilt binaries in /usr.
The patch where libfmodex.so is definately in env.d -> ld.so.conf, in linkers path but it still fails to find -lfmodex. I don't see referencing to the another bug a solution, this worked fine until moved to /opt.
(In reply to comment #7) > The patch where libfmodex.so is definately in env.d -> ld.so.conf, in linkers * The path
just a damn -L/opt/whatever is not good enough to you?
(In reply to comment #9) > just a damn -L/opt/whatever is not good enough to you? > It is. Sorry Diego for causing you this hassle, it was scons based application which didn't respect anything I added to it. Ended up adding the -L by patch to the SConstruct. Again, _really_, _sorry_ for the hassle. The package is fine now, installed in /opt.
