Arch Linux User Repository

I didn't expect that comments are stripped off of leading white space and tabs so the posted patch is a bit mangled. Here it is again: kmod-link.patch: http://sprunge.us/fANI @keenerd Great to hear you're interested in bringing OSS back into the repo. The soundon issue seems to be easy to fix: ossvermagic.patch: http://sprunge.us/iJVQ I could not reproduce the uninstall problem and might need some more details on it. However the deletion of the alsa modules could as well be replaced by some file in /etc/modprobe.d/ that blacklists these modules. @Nowaker I've also uploaded an updated PKGBUILD: http://sprunge.us/HbFQ

Oh great.. so Hannu Savolainen's statement was quite right https://bugs.archlinux.org/task/35672#comment114487 > OSS doesn't use memmove at all so this problem must be caused by some > new version of gcc that geterates calls to memmove. I have never heard > about this kind of problem.

> This removes the dependency on gcc-4.7 and will hopefully allow OSS to be readded to the repo. toksik, awesome! Not to be a BOFH, but if I brought it back into the repos I'd want the nastiest remaining bugs fixed first. The two major issues were 'soundon' and the uninstall script. 'soundon' would sometimes take several minutes to finish. (That was isolated to a single line in the soundon script, didn't look deeper.) The uninstall script had become a complete mess - it was supposed to put the alsa drivers back into place as if nothing happened. Instead you'd have to reinstall the kernel and reboot.

@Nowaker It is soley the OSS developers fault. Either they relied on something that cannot be relied on, especially not when they turn compiler optimizations on by default. It was pure luck that this did not affect OSS in the past. Or they are just doing the wrong thing to build the kernel module. My patch fixes the latter.

@toksik, Thank you very much for your input. I will update all the PKGBUILDs very soon. Is it something worth reporting to GCC issue tracker as a bug? Or it's just oss's fault?

I seem to have finally discovered the actual bug in OSS and was able to fix it properly. This removes the dependency on gcc-4.7 and will hopefully allow OSS to be readded to the repo. The patch below requires setup/Linux/oss/build/osscore.c to be renamed to osscore_wrapper.c (in prepare) and should be applied after all other patches. Explanation: When osscore.ko is loaded by running soundon dmesg shows osscore: no symbol version for memmove osscore: Unknown symbol memmove (err -22) saying two things: 1. The function memmove is called somewhere in the kernel module. Generally this is fine as the linux kernel provides the function. What is interesting is that it is never directly called in the OSS codebase. Instead it is GCC that, in newer versions, sometimes generates calls to memmove as part of its code optimization at optimization level "-O3". To be precise it is an assingment in the function setfragment_error in kernel/framework/audio/oss_audio_core.c that gets optimized in this way. GCC's behaviour is correct and even documented in it's man page. 2. Symbol version information for memmove is missing. The usual way to build a kernel module externally is to use the Makefile provided in /lib/modules/VERSION/build: It takes care of generating symbol version information and linking everything to a .ko kernel module. This is also what OSS does with it's linux kernel wrapper to generate /lib/oss/build/osscore.ko. What it does then is what causes the problem: The main part of OSS /lib/oss/objects/osscore.o, which unfortunately contains the call to memmove, is linked together with this osscore.ko to /lib/modules/extramodules-VERSION/oss/osscore.ko with a conventional "ld". This of course does not take care of symbol versioning so that it is missing for symbols only used in this main part of OSS. The fix is to hand both /lib/oss/build/osscore.c (renamed to osscore_wrapper.c to avoid name conflicts) and /lib/oss/objects/osscore.o (copied by install.sh to osscore_mainline.o) over to the provided Makefile that then generates symbol version information for the whole osscore.ko module. I've successfully tested the patch on x86_64 and i686 with gcc-4.8.2. --- setup/Linux/oss/build/install.sh 2013-11-10 20:56:26.182816531 +0100 +++ setup/Linux/oss/build/install.sh 2013-11-10 21:00:08.858276861 +0100 @@ -203,11 +203,8 @@ exit 3 fi -if ! $LD -r osscore.ko osscore_mainline.o -o /lib/modules/$UNAME/kernel/oss/osscore.ko -then - echo Linking the osscore module failed - exit 5 -fi + +cp -f osscore.ko /lib/modules/$UNAME/kernel/oss/osscore.ko if test -f Module.symvers then --- setup/Linux/oss/build/Makefile.osscore 2013-11-10 20:57:25.732493923 +0100 +++ setup/Linux/oss/build/Makefile.osscore 2013-11-10 20:59:46.185066359 +0100 @@ -5,6 +5,7 @@ ifneq ($(KERNELRELEASE),) obj-m := osscore.o + osscore-y := osscore_wrapper.o osscore_mainline.o else

I tried adding the -L line to CFLAGS and the build failed the same way. Then I ran "pacman -Ql gcc47 | grep '\.a$' " and there weren't any *.a files, so I rebuilt gcc47 and that solved it.

@RunningDroid, I just tried building it to make sure it works. I installed gcc47 and oss from scratch, and got: ==> Finished making: oss 4.2_2008-2 (nie, 20 paź 2013, 12:06:38 CEST) Full log: http://wklej.org/hash/24a5938e5f0/ "cannot find -lgcc" suggests gcc compile-time libs are not available. gcc47 is installed though... Could you please try adding something like this to gcc-4.7 call? -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.3 This is where *.a files reside: pacman -Ql gcc47 | grep '\.a$'

I seem to be having trouble building this, the build fails with "/usr/bin/ld: cannot find -lgcc" makepkg build log: http://sprunge.us/UIAI

@Osune: I think it is unlikely that OSS is picked up by a TU and put into [community] again, because it does not build with Arch's current tool chain, which includes GCC 4.8. Also upstream isn't very active and does not keep up with Linux kernel development very well. This makes it unsuitable for a rolling release distribution. OSS support being dropped from VLC is unfortunate, but understandable from the maintainer's point of view. You could open an issue and nicely request it being readded on the grounds that it does not require any additional dependencies, practically does not increase the size of the package and basically doesn't impact VLC for non-OSS users in any way. Alternatively you could use mplayer, mpv or some GStreamer based video player, all of which still include OSS output. @Tibor: OSS does not build correctly with GCC 4.8 and later. We will only find out, whether this is a bug in GCC or in OSS, if someone which too much time bisects GCC and then locates the offending code in OSS. The gcc47 PKGBUILD was updated to allow installation alongside gcc-multilib. If you have any problems with building gcc47 report it in gcc47's comments. @all: Thank you all for your continued patronage. :P