Found via `codespell -q 3 -S *.po,./share/patchfiles,./libs -L ba,buss,busses,doubleclick,hsi,ontop,ro,seh,siz,sord,sur,te,trough,ue`
Follow-up to 364f2f078
See also af69061644 and b8e1cd53c. This can be useful in
some cases where running a dry-run build will fail.
e.g. with --freedesktop files that are not generated before the
actual build.
This breaks windows builds, since apparently build(bld) is
evaluated twice (once to write compile_commands.json and once
to compile), even though `obj` is reset.
eg. in libs/pbd/wscript
```
if bld.env['build_target'] == 'mingw':
obj.source += [ 'windows_special_dirs.cc' ]
```
results in
[ 65/1159] Compiling libs/pbd/windows_special_dirs.cc
[ 69/1159] Compiling libs/pbd/windows_special_dirs.cc
which then produces an error when linking:
```
/usr/bin/x86_64-w64-mingw32-ld: libs/pbd/windows_special_dirs.cc.2.o:libs/pbd/windows_special_dirs.cc:28: multiple definition of `PBD::get_win_special_folder_path[abi:cxx11](int)'; libs/pbd/windows_special_dirs.cc.2.o:libs/pbd/windows_special_dirs.cc:28: first defined here
```
This enables the generation of build/compile_commands.json
which is a compilation database recognized by some IDE/editors
to provide compiler quality linting.
To name a few:
- Visual Studio Code
- VIM (with ALE plugin)
With glib 2.64, volatile gint produce annoying Wcast-qual
compiler warnings with mingw/gcc-8.
Even though the the build succeeds, and only glib 2.68+
requires non-volatile atomics this results in a much
cleaner build-log.
bind.hpp:36:1: note: ‘#pragma message: The practice of declaring the
Bind placeholders (_1, _2, ...) in the global namespace is deprecated.
Please use <boost/bind/bind.hpp> + using namespace boost::placeholders,
or define BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior.
Older compilers do not yet have fmaintrin.h. This fixes compile errors:
```
x86_functions_fma.cc:51:39: error: '_mm_fmadd_ss' was not declared in this scope
x86_functions_fma.cc:85:35: error: '_mm256_fmadd_ps' was not declared in this scope
x86_functions_fma.cc:106:35: error: '_mm256_fmadd_ps' was not declared in this scope
x86_functions_fma.cc:129:39: error: '_mm_fmadd_ss' was not declared in this scope
```
By supporting FMA extension, the number of instruction needed
for multiply accumulate to mix channels are reduced. Since,
this extension has been around since middle of 2012, more
computers have this instruction set available.
mmacosx-version-min also needs to be set during linking, otherwise
the Finder will not allow to launch the application on older systems
"The application requires os X 10.XX or later"
(with XX being the build-host's OS version), even though
Ardour can be started from a terminal on target due to correct
c/cxxflags.
Apparently gcc-6.2 with -O3 and -mfpu=neon can use ARM instructions
that requires 64bit alignment (here vst1.64) with data that
is not 64bit aligned (g->strcache) https://i.imgur.com/vYktsUn.png
So we need to be able to build "arm_neon_functions.cc" with
-mfpu=neon, while not automatically using NEON for the rest
of the codebase, unless explicitly asked for.
Previously, `dist` had to be the first argument to waf. If it came in a
different position (e.g. `APPNAME=Ardour ./waf tarball dist`) or
`distcheck` was used instead of `dist`, the resulting archive was named
`noname-....tar.bz2`.
Signed-off-by: Nils Philippsen <nils@tiptoe.de>
gcc-8.2 -O3 optimization enables -finline-functions.
For reasons yet unknown this causes issues with Glib::Threads::Private
when loading sessions (creating new ones is fine) and likely some
other operations.
Without this change the following happens (5.12 as well as current git)
when loading an existing session:
---
[Switching to Thread 6092.0x12fc]
Breakpoint 1, ARDOUR::SessionEvent::create_per_thread_pool (name=..., nitems=4096)
at ../libs/ardour/session_events.cc:60
60 in ../libs/ardour/session_events.cc
$6 = (const std::__cxx11::string &) @0x210dfc60: {static npos = 18446744073709551615,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
_M_p = 0x210dfc70 "GUI"}, _M_string_length = 3, {_M_local_buf = "GUI\000\000\000\000\000<E0>P<DA>:\000\000\000",
_M_allocated_capacity = 4805959}}
#0 ARDOUR::SessionEvent::create_per_thread_pool (name=..., nitems=4096) at ../libs/ardour/session_events.cc:60
#1 0x0000000000434e77 in ?? ()
[..]
Thread 1 (Thread 6092.0x12fc):
#0 0x0000000061f152ef in PBD::RingBuffer<void*>::write (this=this@entry=0x50, src=src@entry=0x210dcdc8,
cnt=cnt@entry=1) at ../libs/pbd/pbd/ringbuffer.h:170
#1 0x0000000061ee954d in push (t=<optimized out>, this=0x0) at ../libs/pbd/pool.cc:290
#2 CrossThreadPool::flush_pending_with_ev (this=0x0, ptr=<optimized out>) at ../libs/pbd/pool.cc:254
#3 0x00000000218d5b01 in operator() (a0=0x210dcdc8, this=0x48)
at /home/ardour/win-stack-w64/include/boost/function/function_template.hpp:682
#4 operator()<boost::function<void(ARDOUR::SessionEvent*)>, boost::_bi::list0> (a=<synthetic pointer>, f=...,
this=0x68) at /home/ardour/win-stack-w64/include/boost/bind/bind.hpp:259
#5 operator() (this=0x48) at /home/ardour/win-stack-w64/include/boost/bind/bind.hpp:1294
#6 boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (ARDOUR::SessionEvent*)>, boost::_bi::list1<boost::_bi::value<ARDOUR::SessionEvent*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...)
at /home/ardour/win-stack-w64/include/boost/function/function_template.hpp:159
#7 0x0000000063e2dc39 in operator() (this=0x210dcf70)
at /home/ardour/win-stack-w64/include/boost/function/function_template.hpp:682
#8 AbstractUI<Gtkmm2ext::UIRequest>::call_slot(PBD::EventLoop::InvalidationRecord*, boost::function<void ()> const&)
(this=0x3ada50e0, invalidation=0x0, f=...) at ../libs/pbd/pbd/abstract_ui.cc:434
#9 0x00000000216cbb96 in ARDOUR::SessionEventManager::merge_event (this=<optimized out>, ev=<optimized out>)
at /home/ardour/win-stack-w64/include/boost/function/function_template.hpp:507
#10 0x00000000216e3861 in non-virtual thunk to ARDOUR::Session::queue_event(ARDOUR::SessionEvent*) ()
at ../../win-stack-w64/include/glibmm-2.4/glibmm/threads.h:709
#11 0x00000000216c91bf in ARDOUR::SessionEventManager::clear_events(ARDOUR::SessionEvent::Type, boost::function<void ()>) (this=this@entry=0x4256cc08, type=type@entry=ARDOUR::SessionEvent::Skip, after=...)
at ../libs/ardour/session_events.cc:156
#12 0x000000002168874a in ARDOUR::Session::sync_locations_to_skips (this=this@entry=0x4256ca90)
at /usr/lib/gcc/x86_64-w64-mingw32/8.3-posix/include/c++/new:169
#13 0x0000000021688802 in ARDOUR::Session::update_skips (this=this@entry=0x4256ca90, loc=loc@entry=0x0,
consolidate=consolidate@entry=false) at ../libs/ardour/session.cc:1683
#14 0x0000000021699649 in _locations_changed (locations=..., this=0x4256ca90) at ../libs/ardour/session.cc:1859
#15 apply<ARDOUR::Session> (method=
(void (ARDOUR::Session::*)(ARDOUR::Session * const, const ARDOUR::Locations::LocationList &)) 0x216994f0 <ARDOUR::Session::_locations_changed(std::__cxx11::list<ARDOUR::Location*, std::allocator<ARDOUR::Location*> > const&)>,
obj=..., this=0x40ff4c60) at ../libs/ardour/ardour/location.h:240
#16 ARDOUR::Session::locations_changed (this=this@entry=0x4256ca90) at ../libs/ardour/session.cc:1840
#17 0x0000000021700abd in ARDOUR::Session::set_state (this=0x4256ca90, node=..., version=6000)
at ../libs/ardour/session_state.cc:1657
#18 0x0000000021713456 in ARDOUR::Session::post_engine_init (this=this@entry=0x4256ca90) at ../libs/pbd/pbd/xml++.h:81
#19 0x00000000216ad5cd in ARDOUR::Session::Session (this=0x4256ca90, eng=..., fullpath=..., snapshot_name=...,
bus_profile=<optimized out>, mix_template=...) at ../libs/ardour/session.cc:383
#20 0x000000000046db8b in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
---
Note that in the trace starting at #19 the source-file references
are offset :post_engine_init() isn't in xml++.h
(likely debug symbols are incorrect due to inline functions)
The application crashes due to #2 ::flush_pending_with_ev (this=0x0 ..)
But the earlier breakpoint above shows that the ThreadPool was
created, and this #11 ::clear_events() should not assign NULL.
(This happens on a single-core CPU, too)
luz paz
a1batross
Mads Kiilerich
Remi Thebault
Paul Davis
Ayan Shafqat
Nils Philippsen
Luciano Iam
nia
