[Audacity-devel] Cross-Compiled Audacity

[Darrell Walisser]

After much effort, I have successfully produced a cross-compiled audacity
for Windows on Linux. If you recall, I decided to try this mainly to test
the OpenMP patch on Windows. Well I did, and it works!

There are binaries for download at https://goo.gl/Z6nZQR if you want to try
it out (both openmp and non-openmp). I'm not sure how to test it all but I
haven't seen anything wrong as yet.

The build will be fast and easy with the changes I have made, it will
basically be:
- install mxe (http://mxe.cc/)
- make the mxe packages for a few things that are currently broken
(libsndfile, portaudio)
- build wxWidgets or use the mxe package
- configure audacity and make

Besides OpenMP support on windows, this approach may have other benefits:
- faster compilation (about 5 minutes from "git clean -dfx" to audacity.exe)
- build or test automation since it all happens at linux command prompt
- also runs in wine so tools like memcheck/helgrind could be used to
instrument the windows build

There are a lot of changes, but before I start any pull request I need to
start a discussion on some issues.

1. There are many changes to confgure.ac, Makefile.am etc. I will of course
verify I did not break the build on Linux, but will need help on Mac.
Should I also provide the resulting configure/Makefile.in? Provided that
the autotools version is higher and autotools didn't spew warnings/errors
am I safe?

2. I am using stock wxWidgets from mxe, which means I had to disable the
high dpi fix in audacity. Is audacity/wxWidgets on github the version with
all patches applied? I could try compiling wxWidgets myself and see what
changes.

3. I'm using the static build of wxWidgets from mxe. How important is it to
have a shared wxWidgets library? If this is a top priority I guess I go
there next.

4. I couldn't compile with --std=c++11, I had to use --std=gnu++11 due to
this bug:
http://stackoverflow.com/questions/27285706/trouble-using-wxwidgets-3-0-2-library-under-mingw-64.
Which resulting in link errors. Maybe that could be patched in wxwidgets

5. I had to replace wxIsNan() with std::isnan everywhere, due to another
wxWidgets bug, which will not be fixed according to this pull request:
https://github.com/wxWidgets/wxWidgets/pull/283, this might not work on the
not-quite-there-yet c++11 compilers that we need to support (which are? OS
X...?)

6. I have broken the msvc build since I needed to split the common win32
code out from msvc code in portaudio. But it should be simple to correct,
if someone wants to help that would be nice so I don't have to get a Visual
Studio environment setup.

[James Crook]

Post by Darrell Walisser
After much effort, I have successfully produced a cross-compiled audacity
for Windows on Linux. If you recall, I decided to try this mainly to test
the OpenMP patch on Windows. Well I did, and it works!

Woohoo! This is great.

Post by Darrell Walisser
There are binaries for download at https://goo.gl/Z6nZQR if you want to try
it out (both openmp and non-openmp). I'm not sure how to test it all but I
haven't seen anything wrong as yet.
The build will be fast and easy with the changes I have made, it will
- install mxe (http://mxe.cc/)
- make the mxe packages for a few things that are currently broken
(libsndfile, portaudio)
- build wxWidgets or use the mxe package
- configure audacity and make
- faster compilation (about 5 minutes from "git clean -dfx" to audacity.exe)
- build or test automation since it all happens at linux command prompt
- also runs in wine so tools like memcheck/helgrind could be used to
instrument the windows build

Build automation is huge win for us, provided we follow up on this -
e.g. using a t2.micro instance from Amazon for around $80/year
(including I/O) as a build server.

Post by Darrell Walisser
There are a lot of changes, but before I start any pull request I need to
start a discussion on some issues.
1. There are many changes to confgure.ac, Makefile.am etc. I will of course
verify I did not break the build on Linux, but will need help on Mac.
Should I also provide the resulting configure/Makefile.in? Provided that
the autotools version is higher and autotools didn't spew warnings/errors
am I safe?

Pass. Hope a Mac developer will answer.

Post by Darrell Walisser
2. I am using stock wxWidgets from mxe, which means I had to disable the
high dpi fix in audacity. Is audacity/wxWidgets on github the version with
all patches applied? I could try compiling wxWidgets myself and see what
changes.

No it isn't. It is vanilla still. My intention is that we do apply and
document all the patches there.
I think it makes sense to have one Git branch that has all the patches
for all platforms applied, rather than maintain branches that are
per-platform.

Post by Darrell Walisser
3. I'm using the static build of wxWidgets from mxe. How important is it to
have a shared wxWidgets library? If this is a top priority I guess I go
there next.

For experimental builds static is OK, but mainstream builds must be
built with dynamic linking of the libs. Otherwise we cannot have
plug-ins like mod-nyq-bench which use wxWidgets. It's for the future
openness and extension of Audacity.
Short answer - for Audacity 2.1.4 timescale and likely OpenMP levels of
use in that time, static is fine.

Post by Darrell Walisser
4. I couldn't compile with --std=c++11, I had to use --std=gnu++11 due to
http://stackoverflow.com/questions/27285706/trouble-using-wxwidgets-3-0-2-library-under-mingw-64.
Which resulting in link errors. Maybe that could be patched in wxwidgets

Save ourselves time and use --std=gnu++11.
Already made that choice for our own Audacity code with gcc 4.9.

Post by Darrell Walisser
5. I had to replace wxIsNan() with std::isnan everywhere, due to another
https://github.com/wxWidgets/wxWidgets/pull/283, this might not work on the
not-quite-there-yet c++11 compilers that we need to support (which are? OS
X...?)

That is fine as another patch.

Post by Darrell Walisser
6. I have broken the msvc build since I needed to split the common win32
code out from msvc code in portaudio. But it should be simple to correct,
if someone wants to help that would be nice so I don't have to get a Visual
Studio environment setup.

If it is simple, I can find some time to fix that. I am just a bit
concerned if there are substantial changes to portaudio code - we don't
want them in our release branch for 2.1.3, and would add them at the
start of the 2.1.4 release cycle.

--James.

------------------------------------------------------------------------------

[Gale Andrews]

Post by James Crook

Post by Darrell Walisser
After much effort, I have successfully produced a cross-compiled audacity
for Windows on Linux. If you recall, I decided to try this mainly to test
the OpenMP patch on Windows. Well I did, and it works!

Woohoo! This is great.

Post by Darrell Walisser
There are binaries for download at https://goo.gl/Z6nZQR if you want to try
it out (both openmp and non-openmp). I'm not sure how to test it all but I
haven't seen anything wrong as yet.
The build will be fast and easy with the changes I have made, it will
- install mxe (http://mxe.cc/)
- make the mxe packages for a few things that are currently broken
(libsndfile, portaudio)
- build wxWidgets or use the mxe package
- configure audacity and make
- faster compilation (about 5 minutes from "git clean -dfx" to audacity.exe)
- build or test automation since it all happens at linux command prompt
- also runs in wine so tools like memcheck/helgrind could be used to
instrument the windows build

Build automation is huge win for us, provided we follow up on this -
e.g. using a t2.micro instance from Amazon for around $80/year
(including I/O) as a build server.

Post by Darrell Walisser
There are a lot of changes, but before I start any pull request I need to
start a discussion on some issues.
1. There are many changes to confgure.ac, Makefile.am etc. I will of course
verify I did not break the build on Linux, but will need help on Mac.
Should I also provide the resulting configure/Makefile.in? Provided that
the autotools version is higher and autotools didn't spew warnings/errors
am I safe?

Pass. Hope a Mac developer will answer.

Post by Darrell Walisser
2. I am using stock wxWidgets from mxe, which means I had to disable the
high dpi fix in audacity. Is audacity/wxWidgets on github the version with
all patches applied? I could try compiling wxWidgets myself and see what
changes.

No it isn't. It is vanilla still. My intention is that we do apply and
document all the patches there.
I think it makes sense to have one Git branch that has all the patches
for all platforms applied, rather than maintain branches that are
per-platform.

Post by Darrell Walisser
3. I'm using the static build of wxWidgets from mxe. How important is it to
have a shared wxWidgets library? If this is a top priority I guess I go
there next.

For experimental builds static is OK, but mainstream builds must be
built with dynamic linking of the libs. Otherwise we cannot have
plug-ins like mod-nyq-bench which use wxWidgets. It's for the future
openness and extension of Audacity.
Short answer - for Audacity 2.1.4 timescale and likely OpenMP levels of
use in that time, static is fine.

Post by Darrell Walisser
4. I couldn't compile with --std=c++11, I had to use --std=gnu++11 due to
http://stackoverflow.com/questions/27285706/trouble-using-wxwidgets-3-0-2-library-under-mingw-64.
Which resulting in link errors. Maybe that could be patched in wxwidgets

Save ourselves time and use --std=gnu++11.
Already made that choice for our own Audacity code with gcc 4.9.

Does this mean that we require

./configure CXXFLAGS="-std=gnu++11"

to build Audacity? I'm only using that with gcc 4.9, not 5.x. I don't think
it is spelt out anywhere yet.

Or are we going to change the configure file so the ./configure command
will automatically use --std=gnu++11?


Gale

Post by James Crook

Post by Darrell Walisser
5. I had to replace wxIsNan() with std::isnan everywhere, due to another
https://github.com/wxWidgets/wxWidgets/pull/283, this might not work on the
not-quite-there-yet c++11 compilers that we need to support (which are? OS
X...?)

That is fine as another patch.

Post by Darrell Walisser
6. I have broken the msvc build since I needed to split the common win32
code out from msvc code in portaudio. But it should be simple to correct,
if someone wants to help that would be nice so I don't have to get a Visual
Studio environment setup.

If it is simple, I can find some time to fix that. I am just a bit
concerned if there are substantial changes to portaudio code - we don't
want them in our release branch for 2.1.3, and would add them at the
start of the 2.1.4 release cycle.
--James.

------------------------------------------------------------------------------

[James Crook]

Does this mean that we require ./configure CXXFLAGS="-std=gnu++11"
to build Audacity? I'm only using that with gcc 4.9, not 5.x. I don't think it is spelt out anywhere yet.
Or are we going to change the configure file so the ./configure command will automatically use --std=gnu++11?

I *think* we should change the configure script. We can probably
enforce gcc 4.9+ there at the same time.
--James.


------------------------------------------------------------------------------

[Darrell Walisser]

​​

Post by Gale Andrews

Does this mean that we require ./configure CXXFLAGS="-std=gnu++11"

to build Audacity?
​

​This might not have any effect. --std=c++11 is also set in
audacity/src/Makefile.am​

Post by Gale Andrews

Or are we going to change the configure file so the ./configure command

will automatically use --std=gnu++11?
I *think* we should change the configure script. We can probably
enforce gcc 4.9+ there at the same time.
--James.

​Good idea to change configure.ac. Also, where does the gcc 4.9 requirement
come from?​ According to gcc docs, it was almost complete in 4.8.
https://gcc.gnu.org/gcc-4.8/cxx0x_status.html

[Darrell Walisser]

Post by Darrell Walisser
After much effort, I have successfully produced a cross-compiled audacity
for Windows on Linux. If you recall, I decided to try this mainly to test
the OpenMP patch on Windows. Well I did, and it works!

​Pull request #160 and #161 include all the changes. Still failing in
Travis, no idea why yet. Missing libtool tag, but not sure how it was
supposed to get there in the first place.

The build recipe is as follows;

1. Download and install the MXE cross compiler environment (wherever or in
/opt as shown here).

Post by Darrell Walisser
git clone https://github.com/mxe/mxe.git

​> sudo mv mxe /opt/

Post by Darrell Walisser
sudo chown $USER:$USER /opt/mxe​

2. Compile MXE packages

Post by Darrell Walisser
cd /opt/mxe
make wxwidgets libsndfile libogg libvorbis expat cmake

3. Configure audacity

Post by Darrell Walisser
export PATH=/opt/mxe/usr/bin:$PATH

​>​ ./configure --host=i686-w64-mingw32.static
--with-lib-preference='system local' --enable-openmp
--prefix=/tmp/audacity-win
​> make

Post by Darrell Walisser
make install

​

[Arturo 'Buanzo' Busleiman]

Excelllent work!

On Thu, Sep 1, 2016 at 3:34 PM, Darrell Walisser <

Post by Darrell Walisser
After much effort, I have successfully produced a cross-compiled audacity
for Windows on Linux. If you recall, I decided to try this mainly to test
the OpenMP patch on Windows. Well I did, and it works!

​Pull request #160 and #161 include all the changes. Still failing in
Travis, no idea why yet. Missing libtool tag, but not sure how it was
supposed to get there in the first place.
The build recipe is as follows;
1. Download and install the MXE cross compiler environment (wherever or in
/opt as shown here).

Post by Darrell Walisser
git clone https://github.com/mxe/mxe.git

​> sudo mv mxe /opt/

Post by Darrell Walisser
sudo chown $USER:$USER /opt/mxe​

2. Compile MXE packages

Post by Darrell Walisser
cd /opt/mxe
make wxwidgets libsndfile libogg libvorbis expat cmake

3. Configure audacity

Post by Darrell Walisser
export PATH=/opt/mxe/usr/bin:$PATH

​>​ ./configure --host=i686-w64-mingw32.static
--with-lib-preference='system local' --enable-openmp
--prefix=/tmp/audacity-win
​> make

Post by Darrell Walisser
make install

​
------------------------------------------------------------
------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel