Doug:
> Great minds think alike :)
Whenever anybody says this, I always think "simple minds seldom differ".
A little self-deprecating humor. :)
Thanks for the detail on the OSS issues you found. I hope the OSS team
is able to look into these things so that people can use more powerful
audio programs like audacity on Solaris.
>> 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.
This goes away if you modify the two STTypes.h header files so that it
looks like this:
#if defined (__SUNPRO_C) || defined (__SUNPRO_CC)
#undef ALLOW_OPTIMIZATIONS
#else
#define ALLOW_OPTIMIZATIONS 1
#endif
If the Sun Studio compiler supports these optimizations at a later
date, this can be changed, obviously. Or perhaos we could fix the
code to use mediaLib at some later point. The advantage of using
gcc is that the code will be optimized on x86.
>> 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 think #2 or #3 would be reasonable. Probably makes sense to do the
same with --with-libsndfile and --with-id3tag. Note that id3tag only
adds value if you have mp3 support.
>> 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 :(
I think we probably want to use --with-vorbis, and --without-flac.
Even though we ship FLAC on Solaris, we don't ship the needed C++
headers that audacity needs.
> 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 think that by default it should build so it is as usable as possible
without encouraging people to violate IP. Therefore libmad and probably
id3tag shouldn't be a requirement.
>> 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.
That would be good.
>> - 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...
Probably not that important unless we decide to provide more support
for audacity in the future. I'm not sure that Sun would want to
support wxwidgets, so that might hinder Sun's consideration of
supporting it.
>> - 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.
I think this is the better approach. Linking in a static version is
kind of lame.
> 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....
Yes, gnome-volume-control could use more love. Refer to bugzilla bugs
350667 and 347557 for some nasty hackery that we currently apply to
make things work.
>> 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 :)
Cool. Though I think just making audacity compile against the installed
portaudio is probably better than messing around further to fix the
way it links in the static version.
>> - 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?
No, this isn't needed, but it doesn't hurt.
>> - 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.
Sorry, but I didn't really create any patches. I just hacked around
in the BUILD directory to get everything to build. Since audacity
doesn't follow normal Makefile.am conventions, I'm a bit unsure what
the right way to patch things would be. I don't think any of the work
I did is that tricky, would you be able to add some patches to address
some of the identified issues? I think audacity is a cool program and
it would be good to get the spec file in good shape for people to try
it out. I think the fact that it exposes some OSS issues is also good
since we can catch these problems early and hopefully the OSS team can
fix them before they provide updated OSS libraries for Solaris.
Hopefully they are paying attention. Since building audacity is now
pretty simple that we have a spec file, I'd think they could get
involved now. If we fix the spec files so it also builds without
needing to install the latest SFEgcc package, that just makes it
easier (less work) for people to get involved.
Brian
