On Fri, 24 Apr 2020 23:33:59 -0400 FeRD <ferdnyc@gmail.com> wrote: > Sorry, I realized I might have sent this reply to the wrong bug. Yes, I sent my mail to both of the bugs (am doing now again, I guess). I am also making noise :) > What version of libopenshot is that result from? The Clang namespacing was > fixed with the merge of 2a1fe80[1] on 2019-10-29, and would be included in > both libopenshot-0.2.4 and libopenshot-0.2.5. I used version 0.2.2+dfsg1-1 which is the current version in unstable. I'm not the maintainer; upgrading it is outside of my domain (esp. in light of the following). > That's a merge commit and it touches a bunch of files, but basically all of > our headers now qualify juce symbols with the juce:: namespace prefix, and > the test sources now #define DONT_SET_USING_JUCE_NAMESPACE > which prevents JUCE from exporting its symbols into the global namespace. > > AFAICT that's the only way to prevent UnitTest++ and JUCE from clashing > over ambiguous 'UnitTest' symbols. But all this should have been solved > months ago. > >> I'm uneasy about this and hope that a new release of OpenShot made with >> the practices described in /usr/share/doc/juce-modules-source/README.Debian >> will make an elegant solution. > > Is there a copy of that file online somewhere? It's not part of the JUCE > distribution as far as I can tell, and it's definitely not located at that > path on my Fedora machine. Right, I know what'll pull it all together. It seems that the source for libopenshot includes embedded code copies of JUCE, and code copies are strongly discouraged in Debian, even if they don't make it into the binaries. That file is a Debian-specific README mostly addressed to developers that says to replace bundled copies of JUCE and use the code in package juce-modules- source instead. This approach seems to have not been taken. Coincidentally the embedded code copy discussion just came up on debian-devel, and if no maintainer objects I'll add this to the 'big list' of embedded code copies sometime soonish. I hope this makes clear the nature of the obstacles ahead.
JUCE for Debian
===============
upstream's preferred form of usage of JUCE is to include a verbatim copy of all
used JUCE modules in your application.
This is made explicit in the 'Projucer', JUCE's own software project
management workbench, that will copy (or symlink, or include otherwise) the
modules' source code into your project.
# Projucer for Debian
Installing the following packages will give you the 'Projucer' as Debian
packages while keeping your embedded-module-code workflow:
- juce-tools (contains the Projucer)
- juce-modules-source (contains the source-code for the JUCE modules)
The 'Projucer' as shipped with Debian has the following modification regarding
the once shipped by upstream:
# Debian packages that depend on JUCE
This is a quick guideline for packaging upstream software that uses JUCE for
Debian.
For further implementation details check out the 'iem-plugin-suite' package.
- Build-Depend on 'juce-modules-source'
- Add 'Built-Using: juce-modules-source (= <<version>>)' to debian/control
(replace '<<version>>' with the actual version of 'juce-modules-source', as
obtained with
dpkg-query --show --showformat='${source:Version}' juce-modules-source
E.g. dh based packages might use something like the following in debian/rules:
JUCE_VERSION := $(shell dpkg-query --show --showformat='$${source:Version}' juce-modules-source)
override_dh_gencontrol:
dh_gencontrol -- -Vjuce:BuiltUsing="juce ( = $(JUCE_VERSION) )"
Accompanied by the following in the binary package's section in debian/control:
Built-Using: ${juce:BuiltUsing}
- If needed, dynamically link against the following libraries (as
"juce-modules-source" does not include their sources (as opposed to upstream):
- libjpeg
- libpng
- libflac
- libvorbis libvorbisenc libvorbisfile
- libogg
- zlib
E.g. using something like:
make LDFLAGS="$(pkg-config --libs libpng libjpeg flac vorbis vorbisfile vorbisenc ogg zlib)"
*Alternatively*, resave the JUCE-project with the Debian-packaged 'Projucer'
(>=5.4.4~repack0-3) which will take care of adding these libraries (if
required) to the LinuxMakefile build.
- When compiling for some embedded architectures (notably 'armel', 'mipsel' and
the like), you might need to link against '-latomic'.
The following snippet for d/rules can help inject the library on the required
architectures:
# link with libatomic on architectures without built-in atomic
noatomicarch = $(shell dpkg-architecture -qDEB_HOST_ARCH | egrep -x "(armel|powerpc|powerpcspe|m68k|mips|mipsel|sh4|riscv64)")
ifeq ($(if $(noatomicarch),atomic), atomic)
LDFLAGS += -latomic
endif
*Alternatively*, resave the JUCE-project with the Debian-packaged 'Projucer'
(>=5.4.4~repack0-3) which will take care of adding the relevant flags to the
LinuxMakefile build.
- Also be aware, that Projucer generated makefiles usually include
"-march=native", which is mostly not what you want for a generic baseline CPU
build.
You can override that by setting the TARGET_ARCH make variable
make TARGET_ARCH=""
Attachment:
signature.asc
Description: This is a digitally signed message part.