[Audacity-devel] bug 889 EXPERIMENTAL_MIDI

Discussion:

[Audacity-devel] bug 889 EXPERIMENTAL_MIDI_OUT

Steve the Fiddle

2017-07-18 18:41:54 UTC

Moved to -devel to reduce clutter in bugzilla thread.

Poke wrote in http://bugzilla.audacityteam.org/show_bug.cgi?id=889#c6

"If you're building it with the local version (or via
--with-portaudio=local) then it should fix it."

I've been removing the system version of portaudio19-dev before
building Audacity, and that has been working for a while.

I'd forgotten about "--with-portaudio=local" but tried that now and
pleased to say that works. Nevertheless, I expect that distro
maintainers would be happier if Audacity built using the system
version. Do we have any ideas why it doesn't?

Paul wrote in http://bugzilla.audacityteam.org/show_bug.cgi?id=889#c7

"I don't know what errors Steve got from a system version"

The error is:

"audacity-AudioIO.o: In function `AudioIO::MidiTime()':
/audacity/build/src/../../src/AudioIO.cpp:3984: undefined reference to
`PaUtil_GetTime'
collect2: error: ld returned 1 exit status
Makefile:2350: recipe for target 'audacity' failed'"

Paul wrote:

"What are the steps to determine if you have a system version?"

From a terminal:
sudo dpkg -L portaudio19-dev

If portaudio19-dev is installed, its location will be given. If it's
not installed, it will tell you that the package is not installed.

Also, at the end of running configure (building Audacity), the
terminal output list various libraries like this:

Finished configure:
EXPAT: using SYSTEM libraries
FFMPEG: using SYSTEM libraries
LAME: using SYSTEM libraries
LIBFLAC: using SYSTEM libraries
LIBID3TAG: using SYSTEM libraries
LIBMAD: using SYSTEM libraries
LIBNYQUIST: using LOCAL libraries
LIBSBSMS: using LOCAL libraries
LIBSNDFILE: using SYSTEM libraries
LIBSOUNDTOUCH: using SYSTEM libraries
LIBSOXR: using SYSTEM libraries
LIBTWOLAME: using SYSTEM libraries
LIBVAMP: using SYSTEM libraries
LIBVORBIS: using SYSTEM libraries
LV2: using SYSTEM libraries
PORTAUDIO: using LOCAL libraries
PORTSMF: using SYSTEM libraries
PORTMIDI: using LOCAL libraries
WIDGETEXTRA: using LOCAL libraries
ladspa plugin support: enabled
audiounit plugin support: disabled
VST plugin support: enabled
prefix=/usr/local/

Run 'configure --help' for an explanation of these options,
otherwise run 'make' to build Audacity.

Steve

Paul Licameli

2017-07-18 21:09:19 UTC

Permalink

The problem, as I understand it, is that portaudio is sometimes compiled
as C++, and sometimes as C; this changes how you can link to it. While
PRL's fixed that for the local version, we don't know whether the system
version was compiled as C or C++. This could probably be resolved with a
define and checking for C linkage, using C++ linkage if that fails
(checking using automake, which I think can check linkage)
--Poke

On my Mac I can use the Unix nm command (your path will vary):

nm ~/Library/Developer/Xcode/DerivedData/Audacity-
gkopfutijyptwegarpjfigjtokfb/Build/Products/Debug/libportaudio.a | grep
GetTime

Output may be system dependent, but try it, building first as C then as
C++, and I think this may reveal a difference in the "mangling" of the
symbol name when it is C++.

I have just discovered by experiment that on my Mac, with clang, you can
still get away reverting commit 38fd97b8e26060332ab3e9e000a8882326a70ba7
and then building pa_unix_util.c as C++, because it makes no difference to
the nm output, but that may not be so with g++.

PRL

On Tue, Jul 18, 2017 at 11:41 AM, Steve the Fiddle <

Post by Steve the Fiddle
Moved to -devel to reduce clutter in bugzilla thread.
Poke wrote in http://bugzilla.audacityteam.org/show_bug.cgi?id=889#c6
"If you're building it with the local version (or via
--with-portaudio=local) then it should fix it."
I've been removing the system version of portaudio19-dev before
building Audacity, and that has been working for a while.
I'd forgotten about "--with-portaudio=local" but tried that now and
pleased to say that works. Nevertheless, I expect that distro
maintainers would be happier if Audacity built using the system
version. Do we have any ideas why it doesn't?
Paul wrote in http://bugzilla.audacityteam.org/show_bug.cgi?id=889#c7
"I don't know what errors Steve got from a system version"
/audacity/build/src/../../src/AudioIO.cpp:3984: undefined reference to
`PaUtil_GetTime'
collect2: error: ld returned 1 exit status
Makefile:2350: recipe for target 'audacity' failed'"
"What are the steps to determine if you have a system version?"
sudo dpkg -L portaudio19-dev
If portaudio19-dev is installed, its location will be given. If it's
not installed, it will tell you that the package is not installed.
Also, at the end of running configure (building Audacity), the
EXPAT: using SYSTEM libraries
FFMPEG: using SYSTEM libraries
LAME: using SYSTEM libraries
LIBFLAC: using SYSTEM libraries
LIBID3TAG: using SYSTEM libraries
LIBMAD: using SYSTEM libraries
LIBNYQUIST: using LOCAL libraries
LIBSBSMS: using LOCAL libraries
LIBSNDFILE: using SYSTEM libraries
LIBSOUNDTOUCH: using SYSTEM libraries
LIBSOXR: using SYSTEM libraries
LIBTWOLAME: using SYSTEM libraries
LIBVAMP: using SYSTEM libraries
LIBVORBIS: using SYSTEM libraries
LV2: using SYSTEM libraries
PORTAUDIO: using LOCAL libraries
PORTSMF: using SYSTEM libraries
PORTMIDI: using LOCAL libraries
WIDGETEXTRA: using LOCAL libraries
ladspa plugin support: enabled
audiounit plugin support: disabled
VST plugin support: enabled
prefix=/usr/local/
Run 'configure --help' for an explanation of these options,
otherwise run 'make' to build Audacity.
Steve
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Paul Licameli

2017-07-19 17:22:21 UTC

Permalink

On Wed, Jul 19, 2017 at 1:15 PM, Pokechu22 <

I've tried a fix for this, where it'll instead attempt to link with the
system version as both C and C++ in the checklib, and if it can link as C++
but not C it'll add a define. Then we can attempt to link to either
version. I'm not 100% sure if it works, since my system version is
actually too outdated to test, though (but I tested similar versions and
those were fine).
--Poke

Did you try my suggestions with nm?

Where is this commit?

Is this really what we want? Do we rather want the reassurance that we
have a self-contained source code tree free of system dependencies?

PRL

nm ~/Library/Developer/Xcode/DerivedData/Audacity-gkopfutijyptw
egarpjfigjtokfb/Build/Products/Debug/libportaudio.a | grep GetTime
Output may be system dependent, but try it, building first as C then as
C++, and I think this may reveal a difference in the "mangling" of the
symbol name when it is C++.
I have just discovered by experiment that on my Mac, with clang, you can
still get away reverting commit 38fd97b8e26060332ab3e9e000a8882326a70ba7
and then building pa_unix_util.c as C++, because it makes no difference to
the nm output, but that may not be so with g++.
PRL

On Tue, Jul 18, 2017 at 11:41 AM, Steve the Fiddle <

Paul Licameli

2017-07-19 17:38:23 UTC

Permalink

On Wed, Jul 19, 2017 at 1:30 PM, Pokechu22 <

I should clarify: it checks the system version and uses if it can (but in
more cases now), but if it can't, it still uses the local version. It
still requires changing the lib-src version to use extern "C", so that we
have a consistent build there.
I've looked at it with nm before but I'm not entirely sure how to read the
output, as at least on my machines the output both looked the same (no
mangling at all was evident) other than the length of the number before
(which I assume is a 32-bit/64-bit thing).
The commits in question are 62d5d8e8d
<https://github.com/Pokechu22/audacity/commit/62d5d8e8d41b2de86498284a90564d3cfa93b1ba> (relates
to portaudio automake) and 0cd6f761a
<https://github.com/Pokechu22/audacity/commit/0cd6f761a03ae833b37eeb4d10a262cbe39ae240> (using
the prior changes for including), though 059d3a503
<https://github.com/Pokechu22/audacity/commit/059d3a503fc7289fa41efa03f9fa5e90f8d44772> (relates
to portmidi automake) is also a prerequisite to that.
--Poke

Steve, will you test those commits and push them?

PRL

Post by Paul Licameli

Did you try my suggestions with nm?
Where is this commit?
Is this really what we want? Do we rather want the reassurance that we
have a self-contained source code tree free of system dependencies?
PRL

On Tue, Jul 18, 2017 at 3:51 PM, Pokechu22 <

The problem, as I understand it, is that portaudio is sometimes
compiled as C++, and sometimes as C; this changes how you can link to it.
While PRL's fixed that for the local version, we don't know whether the
system version was compiled as C or C++. This could probably be resolved
with a define and checking for C linkage, using C++ linkage if that fails
(checking using automake, which I think can check linkage)
--Poke

nm ~/Library/Developer/Xcode/DerivedData/Audacity-gkopfutijyptw
egarpjfigjtokfb/Build/Products/Debug/libportaudio.a | grep GetTime
Output may be system dependent, but try it, building first as C then as
C++, and I think this may reveal a difference in the "mangling" of the
symbol name when it is C++.
I have just discovered by experiment that on my Mac, with clang, you
can still get away reverting commit 38fd97b8e26060332ab3e9e000a8882326a70ba7
and then building pa_unix_util.c as C++, because it makes no difference to
the nm output, but that may not be so with g++.
PRL

On Tue, Jul 18, 2017 at 11:41 AM, Steve the Fiddle <

Steve the Fiddle

2017-07-19 23:23:16 UTC

Permalink

Post by Paul Licameli
On Wed, Jul 19, 2017 at 1:30 PM, Pokechu22

I should clarify: it checks the system version and uses if it can (but in
more cases now), but if it can't, it still uses the local version. It still
requires changing the lib-src version to use extern "C", so that we have a
consistent build there.
I've looked at it with nm before but I'm not entirely sure how to read the
output, as at least on my machines the output both looked the same (no
mangling at all was evident) other than the length of the number before
(which I assume is a 32-bit/64-bit thing).
The commits in question are 62d5d8e8d (relates to portaudio automake) and
0cd6f761a (using the prior changes for including), though 059d3a503 (relates
to portmidi automake) is also a prerequisite to that.
--Poke

Steve, will you test those commits and push them?

Could you clarify exactly which commits you want me to test.

Steve

Post by Paul Licameli
PRL

Post by Paul Licameli
On Wed, Jul 19, 2017 at 1:15 PM, Pokechu22

I've tried a fix for this, where it'll instead attempt to link with the
system version as both C and C++ in the checklib, and if it can link as C++
but not C it'll add a define. Then we can attempt to link to either
version. I'm not 100% sure if it works, since my system version is actually
too outdated to test, though (but I tested similar versions and those were
fine).
--Poke

Did you try my suggestions with nm?
Where is this commit?
Is this really what we want? Do we rather want the reassurance that we
have a self-contained source code tree free of system dependencies?
PRL

On Tue, Jul 18, 2017 at 3:51 PM, Pokechu22

The problem, as I understand it, is that portaudio is sometimes
compiled as C++, and sometimes as C; this changes how you can link to it.
While PRL's fixed that for the local version, we don't know whether the
system version was compiled as C or C++. This could probably be resolved
with a define and checking for C linkage, using C++ linkage if that fails
(checking using automake, which I think can check linkage)
--Poke

nm
~/Library/Developer/Xcode/DerivedData/Audacity-gkopfutijyptwegarpjfigjtokfb/Build/Products/Debug/libportaudio.a
| grep GetTime
Output may be system dependent, but try it, building first as C then as
C++, and I think this may reveal a difference in the "mangling" of the
symbol name when it is C++.
I have just discovered by experiment that on my Mac, with clang, you
can still get away reverting commit 38fd97b8e26060332ab3e9e000a8882326a70ba7
and then building pa_unix_util.c as C++, because it makes no difference to
the nm output, but that may not be so with g++.
PRL

On Tue, Jul 18, 2017 at 11:41 AM, Steve the Fiddle

Post by Steve the Fiddle
Moved to -devel to reduce clutter in bugzilla thread.
Poke wrote in http://bugzilla.audacityteam.org/show_bug.cgi?id=889#c6
"If you're building it with the local version (or via
--with-portaudio=local) then it should fix it."
I've been removing the system version of portaudio19-dev before
building Audacity, and that has been working for a while.
I'd forgotten about "--with-portaudio=local" but tried that now and
pleased to say that works. Nevertheless, I expect that distro
maintainers would be happier if Audacity built using the system
version. Do we have any ideas why it doesn't?
Paul wrote in http://bugzilla.audacityteam.org/show_bug.cgi?id=889#c7
"I don't know what errors Steve got from a system version"
/audacity/build/src/../../src/AudioIO.cpp:3984: undefined reference to
`PaUtil_GetTime'
collect2: error: ld returned 1 exit status
Makefile:2350: recipe for target 'audacity' failed'"
"What are the steps to determine if you have a system version?"
sudo dpkg -L portaudio19-dev
If portaudio19-dev is installed, its location will be given. If it's
not installed, it will tell you that the package is not installed.
Also, at the end of running configure (building Audacity), the
EXPAT: using SYSTEM libraries
FFMPEG: using SYSTEM libraries
LAME: using SYSTEM libraries
LIBFLAC: using SYSTEM libraries
LIBID3TAG: using SYSTEM libraries
LIBMAD: using SYSTEM libraries
LIBNYQUIST: using LOCAL libraries
LIBSBSMS: using LOCAL libraries
LIBSNDFILE: using SYSTEM libraries
LIBSOUNDTOUCH: using SYSTEM libraries
LIBSOXR: using SYSTEM libraries
LIBTWOLAME: using SYSTEM libraries
LIBVAMP: using SYSTEM libraries
LIBVORBIS: using SYSTEM libraries
LV2: using SYSTEM libraries
PORTAUDIO: using LOCAL libraries
PORTSMF: using SYSTEM libraries
PORTMIDI: using LOCAL libraries
WIDGETEXTRA: using LOCAL libraries
ladspa plugin support: enabled
audiounit plugin support: disabled
VST plugin support: enabled
prefix=/usr/local/
Run 'configure --help' for an explanation of these options,
otherwise run 'make' to build Audacity.
Steve
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel