On Fri, Apr 15, 2016 at 09:24:15AM +0200, Stefan Richter wrote:
> gcc 5.2.0 reports this as an error:
> function ???int* __errno_location()??? is initialized like a variable
> int errno = 0;
> ^
Thanks. Applied (r2605).
jonathan
Hi Stefan
On Thu, Apr 14, 2016 at 11:04:15PM +0200, Stefan Richter wrote:
> On Apr 14 Stefan Richter wrote:
> > I tried multiple things, among them
> > $ export CXXFLAGS=-std=c++11
> > $ export CUSTOM_ENV=True
> > $ scons -c
> > $ scons
> > but so far I did not manage to inspire scons to add -std=c++11 to the gcc
> > command line.
>
> The syntax is
> $ CXXFLAGS="-std=c++11" scons CUSTOM_ENV=True
> or alternatively
> $ CXXFLAGS="--std=c++11" scons CUSTOM_ENV=True
> and it is highly effective. The build now goes through with lots of
> warnings but without error... until the build descends into the support/
> directory.
Right. So what do we take away from this? Do we need to modify the ffado
scons script to add "-std=c++11" whenever a certain version of gcc is in
use? Is the problem specific to gentoo? Is it something FFADO does, or is
it a problem between certain gcc versions and the versions of libraries such
as libxml++ which are used by FFADO?
> This is how a re-run of scons looks like (after src/ was built successfully
> in a previous run, and now support/ is to be built):
>
> [...]
> scons: Building targets ...
> scons: `src' is up to date.
> g++ -o support/dbus/test-dbus.o -c -std=c++11 -m64 -Wall -g -fPIC -Wno-unused-but-set-variable -DDEBUG -DDEBUG_MESSAGES -DDBUS_HAS_THREADS_INIT_DEFAULT -DDBUS_API_SUBJECT_TO_CHANGE -I. -Isrc -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/dbus-c++-1 -I/usr/local/include -I/usr/include/libxml++-2.6 -I/usr/lib64/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include support/dbus/test-dbus.cpp
> In file included from /usr/include/dbus-c++-1/dbus-c++/dbus.h:28:0,
> from support/dbus/controlclient.h:29,
> from support/dbus/test-dbus.cpp:30:
> /usr/include/dbus-c++-1/dbus-c++/types.h:194:20: error: redefinition of âstruct DBus::type<int>â
> template <> struct type<int32_t>
> ^
> /usr/include/dbus-c++-1/dbus-c++/types.h:180:20: error: previous definition of âstruct DBus::type<int>â
> template <> struct type<int16_t>
> ^
To my naive eye this appears to be a problem with the dbus-c++ headers in
combination with the gcc version in use. Which version of dbus-c++ is
installed? I'm away from my development machine at present so I can't take
a look at this file right now: either your compilation environment is
setting defines which result in the redefinition, or the redefinition has
always been present but is now triggering an error instead of a warning
under the newer gcc version. Comments?
> As soon as I remove -std=c++11, the build fails again already in src/.
Right. There appear to be two problems then.
1) It looks like we need this "-std=c++11" flag under some circumstances
which are yet to be fully determined.
2) Newer compilers may require the treatment of some errors as warnings
in order to work with dbus-c++, unless there's a fixed dbus-c++ which
addresses the problems.
Added to this is the success of the Debian build as pointed out by Adrian.
Do we have any obvious patterns emerging yet?
Comments are welcome: since I'm not able to recreate the compilation problem
on my systems I can't contribute all that much to the ongoing experiments
and tests.
Regards
jonathan
Hello! I've released the new version of the sound editor EKO:
http://semiletov.org/ekohttps://github.com/psemiletov/eko
This release features FX presets engine, and the new effect Vynil Taste
that simulates vynil plate noises. EKO is based on Qt5, libsndfile,
portaudio and libsamplerate.
--
Петр Семилетов,
сайт: semiletov.org
текстовый редактор TEA: semiletov.org/tea
Киевоград (неформальное краеведение Киева): www.kievograd.org
On Thu, Apr 14, 2016 at 03:25:37PM +0200, Stefan Richter wrote:
> On Apr 14 Jonathan Woithe wrote:
> > On Thu, Apr 14, 2016 at 09:30:21AM +0200, Stefan Richter wrote:
> > > gcc (Gentoo 4.9.3 p1.2, pie-0.6.3) 4.9.3"
> > > [...]
> > > Build log: http://pastebin.com/fRHScVVH
> > >
> > > Not sure what changed since the last successful build. gcc was possibly
> > > the same.
> >
> > In Nikita's report the errors are reported in src/libutil/cmd_serialize.h.
> > This file hasn't been changed for ages and certainly not any time this year.
> > There may be something rather obscure going on, but it's hard to see that
> > any changes have been made to FFADO to cause Nikita's errors. I wonder
> > there is something strange going on with the compiler or the compilation
> > environment.
> >
> > In Stefan's report the error is different:
>
> Unlike Nikita, I haven't added -std=c++11 yet.
Yes, so it seems - my bad. Somehow I managed to convince myself that I'd
seen it in the pastebin log you posted, but I've just rechecked it and it
clearly isn't in there. Evidently I need more sleep.
> > /usr/include/glibmm-2.4/glibmm/ustring.h:267:12: error: expected â?????;â?????? at
> > end of member declaration
> > ~ustring() noexcept;
> > ^
> >
> > This file is included via libxml++'s exception.h header file. I know there
> > have been some issues with libxml++ and newer gcc versions so I wonder
> > whether any of those are behind this. I remember that libxml++ did throw me
> > some curveballs when I moved my development system from gcc 4.5.x to 4.8.x
> > but I can't remember the details - I'll look them up tonight. It wasn't
> > anything that affected FFADO though.
>
> On the mainline Gentoo package repo (the only one which I use), there are
> now only the packages
> dev-cpp/libxmlpp-2.38.1
> dev-cpp/libxmlpp-2.40.1
> available. I have 2.40.1 installed right now; downgrading to 2.38.1 is
> currently impossible since its build fails as described in
> https://bugs.gentoo.org/show_bug.cgi?id=567526.
A downgrade of libxmlpp is probably not needed since it seems you have the
same version that resulted in a successful build in the Debian build log
that Adrian linked to.
> Note that my build log also contains errors in
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/exception for
> example.
Yes, further down the log. They are of the same form as the ustring.h
errors though, so whatever's tripping ustring.h up is probably responsible
for the g++-v4/exception woes as well.
> The Debian build log with successful build, which Adrian linked to, lists
> the following Debian package versions:
> gcc-5_5.2.1-26
> libxml++2.6-dev_2.40.1-1
> libglibmm-2.4-dev_2.46.2-1
> etc.
>
> I guess I attempt an upgrade to gcc-5 next.
It's strange, since I think you mentioned that the same thing happened for
you with a gcc 4.8.x on that system. I guess 4.9.x could break something
which worked in 4.8.x but such behaviour would be more likely with gcc 5.
Still, stranger things have happened, and there's still the issue that the
Debian build worked fine.
> On Apr 14 Jano Svitok wrote:
> > can you add -std=c++11 to CXX_FLAGS or how is it called to enable C++11
> > extensions? Most of the errors come from these - noexcept, override,...
>
> I tried multiple things, among them
> $ export CXXFLAGS=-std=c++11
> $ export CUSTOM_ENV=True
> $ scons -c
> $ scons
> but so far I did not manage to inspire scons to add -std=c++11 to the gcc
> command line.
So where did it come from? It must be something the ebuild is adding.
Regards
jonathan
On Thu, Apr 14, 2016 at 10:24:05AM +0200, Stefan Richter wrote:
> On Apr 14 Stefan Richter wrote:
> > gcc (Gentoo 4.9.3 p1.2, pie-0.6.3) 4.9.3"
> > [...]
> > Build log: http://pastebin.com/fRHScVVH
> >
> > Not sure what changed since the last successful build. gcc was possibly
> > the same.
>
> Build fails in the same way with gcc (Gentoo 4.8.5 p1.3, pie-0.6.2) 4.8.5.
Current svn builds fine for me in Slackware 14.1: gcc 4.8.2, libxml++
2.37.2, dbus-c++ git from Nov 2014, glibmm 2.36.2. My compilation lines do
*not* include "-std=c++11", so I wonder whether the presence of that is the
root cause for the trouble. My typical g++ call is
g++ -o src/dice/dice_avdevice.os -c -m64 -Wall -g -Werror -fPIC -fPIC ...
This is in a multilib x86_64 environment, so "-m64" is expected. I don't
think the "-std=c++11" should be specified; it would be interesting to query
the ebuild commit log to see what reason was given when it was added
(assuming that this is where it's coming from). Is there a way for you to
hack the build script to get rid of it so this theory can be tested?
Also, following up on my earlier comment about libxml++, I checked my logs
and the problem I was thinking about wasn't a compilation error, but was
related to the chasing the cause of warnings in a couple of libraries. It's
therefore not relevant here.
Regards
jonathan
On Thu, Apr 14, 2016 at 09:30:21AM +0200, Stefan Richter wrote:
> > On 04/13/16 20:27, Nikita Zlobin wrote:
> > > Hello, i'm trying to build libffado from proaudio overlay.
> [...]
> > > Somewhat long time ago (about year) i could install it, but now i have
> > > following problems on compilation:
> > > - First, it seems, that it now uses more modern language features: the
> > > specified option --std=c99, added by one of ebuild's patch, as well
> > > as without any options (tried to build tarball with) gives long error
> > > list.
> > > - With compiler flag --std=c++11 compilation continued for relatively
> > > long time, but then failed with following
> > > errors: http://pastebin.com/hkttBN9X
>
> Building from a recent ffado.org SVN checkout worked for me on Gentoo
> sometime earlier this year.
>
> But right now it fails to build for me too.
> $ gcc --version
> gcc (Gentoo 4.9.3 p1.2, pie-0.6.3) 4.9.3"
> [...]
> Build log: http://pastebin.com/fRHScVVH
>
> Not sure what changed since the last successful build. gcc was possibly
> the same.
In Nikita's report the errors are reported in src/libutil/cmd_serialize.h.
This file hasn't been changed for ages and certainly not any time this year.
There may be something rather obscure going on, but it's hard to see that
any changes have been made to FFADO to cause Nikita's errors. I wonder
there is something strange going on with the compiler or the compilation
environment.
In Stefan's report the error is different:
/usr/include/glibmm-2.4/glibmm/ustring.h:267:12: error: expected â;â at
end of member declaration
~ustring() noexcept;
^
This file is included via libxml++'s exception.h header file. I know there
have been some issues with libxml++ and newer gcc versions so I wonder
whether any of those are behind this. I remember that libxml++ did throw me
some curveballs when I moved my development system from gcc 4.5.x to 4.8.x
but I can't remember the details - I'll look them up tonight. It wasn't
anything that affected FFADO though.
Regards
jonathan
Hello, i'm trying to build libffado from proaudio overlay. The problem
seems to be in ffado itself.
Somewhat long time ago (about year) i could install it, but now i have
following problems on compilation:
- First, it seems, that it now uses more modern language features: the
specified option --std=c99, added by one of ebuild's patch, as well
as without any options (tried to build tarball with) gives long error
list.
- With compiler flag --std=c++11 compilation continued for relatively
long time, but then failed with following
errors: http://pastebin.com/hkttBN9X
there seems to be one common feature: definition with "quadlet_t"
argument fails to overload same def with "byte_t" arg.
I looked to src/libutil/cmd_serialize.h, and there are four (with
original) variants for each functions... i don't understand, why only
quadlet_t - typed variant fails, while others proceed. What i found yet
is that this type is defined in raw1394 headers:
$ grep -r 'quadlet_t;' /usr/include
/usr/include/libraw1394/raw1394.h:typedef u_int32_t quadlet_t;
And what is interesting, when i tried to build from tarball manually:
$ scons -DCOMPILE_FLAGS='--std=c++11'
... that flag was not even passed to g++, so thanks for gentoo S).
-------------
$ gcc --version
gcc (Gentoo 4.9.3 p1.5, pie-0.6.4) 4.9.3
Hello all,
Sadly I won't be able to make it to the miniLAC as work keeps
me in München during the weekend :-(
For those who'll be there, have a good time !
Meanwhile I'm trying to understand the following:
I'm using a Novation LaunchControl (8 pads and 16 rotary controllers).
When I use it via ALSA sequencer, I get the expected MIDI events:
note on/off, controller, and sysex.
When I access it directly as a USB device using libusb, I see
the expected MIDI data, but with some extra bytes, e.g. (all
values in hex):
[09] 90 09 7f (note on)
[08] 80 09 00 (note off)
[0b] b0 15 23 (controller)
[04] f0 00 20 [04] 29 02 0A [07] 77 00 ff (sysex)
where the bytes in [] are the ones that are *not* part of
the MIDI message.
Now since things work perfectly with ALSA sequencer without
required a specific driver, either
* ALSA knowns about the details of this particular device,
* or these extra bytes are part of some standard.
Given that there seems to be one extra byte for every three
expected ones, could it be that this is some format that
encodes 24 bits in 32 ?
lsusb output for this device is:
Bus 003 Device 004: ID 1235:0034 Focusrite-Novation
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1235 Focusrite-Novation
idProduct 0x0034
bcdDevice 0.00
iManufacturer 1 Focusrite A.E. Ltd
iProduct 2 Launch Control
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 82
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 60mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 0
iInterface 3 Launch Control
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 9
bInCollection 1
baInterfaceNr( 0) 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 3 MIDI Streaming
bInterfaceProtocol 0
iInterface 3 Launch Control
MIDIStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 46
MIDIStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (MIDI_IN_JACK)
bJackType 1 Embedded
bJackID 1
iJack 0
MIDIStreaming Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (MIDI_OUT_JACK)
bJackType 1 Embedded
bJackID 2
bNrInputPins 1
baSourceID( 0) 1
BaSourcePin( 0) 1
iJack 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
MIDIStreaming Endpoint Descriptor:
bLength 5
bDescriptorType 37
bDescriptorSubtype 1 (GENERAL)
bNumEmbMIDIJack 1
baAssocJackID( 0) 2
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
MIDIStreaming Endpoint Descriptor:
bLength 5
bDescriptorType 37
bDescriptorSubtype 1 (GENERAL)
bNumEmbMIDIJack 1
baAssocJackID( 0) 1
Any info much appreciated !!
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)