Brian Cameron wrote:
> Doug:
>
>> I have just committed the spec files and patches for audacity to the
>> spec-files-extra repository on sourceforge.
>
> Funny timing. I was looking into building a spec file for Audacity at
> the same time as you, but you beat me to it.
Great minds think alike :)
>
>> It needs the latest build of SFEgcc which used gnu ld and contains
>> the Intel mmx API. Also SFEwxwidgets-gnu needs to be rebuilt with
>> SFEgcc. My testing so far shows there are some issues with the oss
>> drivers which need to be fixed.
>
> What issues have you found with the OSS drivers? I'm cc:ing the
> OpenSound-ext at sun.com mailing list, so that the OSS team can look
> into this. Now that we have a working SFEaudacity.spec file, perhaps
> the OSS team can look into why there are problems using it on Solaris.
>
OSS issues
--------------
root at prae> uname -a
SunOS prae 5.11 snv_72 i86pc i386 i86pc
root at prae> pkginfo -l oss | grep VERSION
VERSION: v4.0-1004
Issue 1) I am having problems when audacity (actually portaudio) is
opening /dev/dsp with O_NONBLOCK. It almost always seems to return an
EBUSY errno. "The ...... below is the previous line repeated several times"
doug at prae> audacity
Expression 'tempDevHandle = open( deviceInfo->name, flags )' failed in
'src/hostapi/oss/pa_unix_oss.c', line: 687
.......
Expression '*idev = open( idevName, flags )' failed in
'src/hostapi/oss/pa_unix_oss.c', line: 807
Expression 'OpenDevices( idevName, odevName, &idev, &odev )' failed in
'src/hostapi/oss/pa_unix_oss.c', line: 861
Expression 'PaOssStream_Initialize( stream, inputParameters,
outputParameters, streamCallback, userData, streamFlags, ossHostApi )'
failed in 'src/hostapi/oss/pa_unix_oss.c', line: 1226
Expression 'tempDevHandle = open( deviceInfo->name, flags )' failed in
'src/hostapi/oss/pa_unix_oss.c', line: 687
.......
------------------------------------------------------------------------------------------------------------------------
Issue 2) The occasional kernel panic....
panic[cpu0]/thread=ffffff00d25a9ca0:
BAD TRAP: type=e (#pf Page fault) rp=ffffff0002f98950 addr=2 occurred
in module
"osscore" due to a NULL pointer dereference
audacity:
#pf Page fault
Bad kernel fault at addr=0x2
pid=1108, pc=0xfffffffff8627c20, sp=0xffffff0002f98a40, eflags=0x10282
cr0: 80050033<pg,wp,ne,et,mp,pe> cr4: 6f8<xmme,fxsr,pge,mce,pae,pse,de>
cr2: 2 cr3: 31f3000 cr8: c
rdi: 0 rsi: ffffff00cf7e4608 rdx: ffffff0002f98a98
rcx: ffffff0002f98af8 r8: 0 r9: ffffff0002f98af8
rax: 0 rbx: 0 rbp: ffffff0002f98a70
r10: ffffff0002f98a88 r11: ffffffffc0356480 r12: 0
r13: ffffff0002f98e1c r14: ffffff00cf023040 r15: ffffff00cec6fa70
fsb: 0 gsb: fffffffffbc27010 ds: 4b
es: 4b fs: 0 gs: 1c3
trp: e err: 0 rip: fffffffff8627c20
cs: 30 rfl: 10282 rsp: ffffff0002f98a40
ss: 38
ffffff0002f98830 unix:die+c8 ()
ffffff0002f98940 unix:trap+1351 ()
ffffff0002f98950 unix:_cmntrap+e9 ()
ffffff0002f98a70 osscore:oss_register_poll+30 ()
ffffff0002f98ad0 osscore:oss_audio_chpoll+36b ()
ffffff0002f98b40 osscore:oss_chpoll+178 ()
ffffff0002f98b80 genunix:cdev_poll+44 ()
ffffff0002f98bc0 specfs:spec_poll+73 ()
ffffff0002f98c20 genunix:fop_poll+36 ()
ffffff0002f98cc0 genunix:pcache_insert+66 ()
ffffff0002f98d60 genunix:pcacheset_cache_list+102 ()
ffffff0002f98e40 genunix:poll_common+349 ()
ffffff0002f98ec0 genunix:pollsys+ec ()
ffffff0002f98f10 unix:brand_sys_syscall32+1a3 ()
syncing file systems...
done
> ---
>
> I was able to build audacity okay with Sun Studio instead of needing
> SFEgcc. I did need to build SFEwxwidgets-gnu and SFEpulseaudio.
Good stuff. I reverted to SFEgcc when Sun Studio balked on some mmx
instructions that were inlined in the code. I probably need to add the
latest Sun Studio patches.
> I don't like the fact that libmad is listed as a dependency. This
> dependency should be removed, I think. We shouldn't force people to
> link in modules that contain IP. audacity works just fine without mp3
> support. Users who want mp3 support can build libmad before they
> build SFEaudacity if they want, but SFEaudacity shouldn't require
> it.
Agreed. I notice some of the Linux spec files wrap configure options.
Of the top of my head we could
1) "opt-in" We could require a "--with-libmad" be added to the
pkgtool command. If it is not in the pkgtool command line, then
"--without-libmad" is added to the configure command and the
dependencies are not added to the package
2) "auto" The spec-file checks to see if you have SFElibmad on your
system and adds the required configure option and package dependency
3) "silent" Not include any options and if configure finds it, then
it will add it to build. No package dependency is added. My biggest
problem with this is for people who want to distribute packages.
> I notice that SFElibsamplerate and SFElibid3tag are also listed
> as dependencies. I didn't build with these. Why are these listed
> as required if they aren't really needed? Or is my build of audacity
> broken in some way since I didn't build with these?
I was adding the dependencies from the logs :(
This is more of a general issue of what is the default build
requirements of the spec files. I know some people want everything
added, some want only certain options added, and others want only the
minimum dependencies. Do we have an build options that tries to satisfy
most. Say "minimum", "default" or "recommended", and "everything". I
don't like it where configure adds a dependency during the build and is
not recorded in the package.
> I had to make a few additional changes, to get it to build with
> Sun Studio. I didn't really get to the point where I can provide
> patches, but I can explain the hacks I had to do.
>
> - I hacked the SFEaudacity.spec file to not set dbgopt, and also
> commented out these lines:
>
> +#perl -pi -e 's/-M ...wl./--version-script=/'
> lib-src/portaudio-v19/libtool
> +#perl -pi -e 's/-Wl,-zignore -Wl,-zcombreloc -Wl,-Bdirect//'
> src/Makefile
> +#perl -pi -e 's/-Wl,-zignore -Wl,-zcombreloc -Wl,-Bdirect//'
> tests/Makefile
>
> Perhaps the spec file could be made smarter so it only does the
> above when building with gcc ld? Or maybe we can get rid of this
> cruft if we just fix the spec file so it builds with either linker?
>
Yeah, I have a "using_gld" test in SFEwxwidgets-gnu.spec. I do not like
it much as it depends on which gcc it finds in the command like. I have
been think of writing some wrappers which we could use for
cc,gcc,CC,g+,and ld. The personality could be changed by using and
environment variable, i.e. cc->gcc and it would filter out, modify, or
correct options which are meant for a different compiler. Such that
-Wall and -pthread would be a problem of the past.
> - In the following two header files, I needed to fix them so that
> ALLOW_SSE doesn't get set. I just commented out the setting of
> the #define, but it would probably be better to fix these header
> files so that ALLOW_SSE only gets set if the right version of GCC
> is used.
>
> lib-src/soundtouch/include/STTypes.h
> lib-src/soundtouch/soundtouch/STTypes.h
>
> Or perhaps just unsetting ALLOW_OPTIMIZATIONS in these header files
> might be better if building with Sun Studio? Perhaps we could use
> mediaLib here for better Sun support?
>
> #ifdef __SUNPRO_C is the right ifdef for Sun Studio C compiler &
> #ifdef __SUNPRO_CC is the right ifdef for Sun Studio C++ compiler.
Hand coded assembler is always a problem. I think mediaLib would be the
best option if we can. I have never got around to actually coding with
it as yet...
>
> - I needed to rerun configure in lib-src/portaudio-v19 so that it
> doesn't try to use -version-script when linking. I think this is
> the only thing that really requires the new gcc linker. I needed to
> include the --disable-flac option when running configure so it didn't
> try to link in the nonexistant FLAC C++ header files.
>
We could always make it use SFEportaudio rather than building as a
static library. I did this for libtwolame so people could build audacity
with the system libtwolame if they desired. Such patches should be easy
to send back upstream.
Also I am playing around with adding a sunaudio port to portaudio. This
has given me a few ideas on making a generic audio mixer which can
handle both OSS and sunaudio. gnome-volume-control could do with some
spice'in up. This discussion is probably better for another email....
> I also found the generated Makefile had a few problems that I
> hacked around:
>
> - Sun Studio doesn't like the -pthread argument. I removed this.
> - SUBDIRS is set to nothing, and this makes the following commands
> mad:
>
> for dir in $(SUBDIRS); do make -C $$dir all; done
>
> It seems Makefile doesn't like it when $(SUBDIRS) is empty. So I
> hacked the Makefile to not do this.
>
> Probably should fix the configure/Makefile generation so that it
> builds properly when using Sun Studio.
My test portaudio build has it hacked out of the makefile. It is on my
list to write a patch :)
> - I noticed PA_LIBS in src/Makefile wasn't getting set by configure
> properly. Not sure why, so I just hacked src/Makefile to link in
> -lportaudio -lm -lpthread, which is the value in the
> lib-src/portaudio-v19/portaudio-2.0.pc file. Probably need to fix
> the top-level configure.ac so it does this so it works on Solaris?
Is -lpthread needed? Isn't this all actually in libc now?
>
> - I needed to fix src/Makefile so that the GTK libraries got included
> on the link statement. Sun Studio is more picky that dependent
> libraries be listed.
>
> After doing all this, I can run audacity building with Sun Studio.
>
> - I found if I prune the LINGUAS in locale/Makefile to the following, I
> don't need to update SFEgettext. This might be handy information for
> people who want to build this, but who don't want to update gettext.
>
> LINGUAS=af ar bn bg ca cs cy el es eu fi ga gl hu it ja lt mk nl pt ro
> ru sk sl sv tr zh
Could you commit the changes to SFE so I can try them.
Thanks
Doug
