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)
Hi all,
I have created a template to set up a DISTRHO Plugin Framework effect
plugin project quickly using the (Python) tool cookiecutter.
https://github.com/SpotlightKid/cookiecutter-dpf-effect
When you have installed cookiecutter, you create a new project with:
cookiecutter https://github.com/SpotlightKid/cookiecutter-dpf-effect
A directory named after the value you gave for repo_name (e.g.
"simplegain") will be created and initialized as a git repository and
DPF added as a git submodule.
Enter the directory and run make:
cd <repo_name>
make
The template compiles a simple gain plugin. Change the implementation in
plugins/<plugin_name>/Plugin<plugin_name>.cpp as needed.
Share & Enjoy!
Chris
Hi everyone
As some of you might know, part of the MOD Team is going to be at the Musikmesse from April 7th to 10th.
Unfortunately it clashes with the miniLAC so, differently from last year’s LAC, we won’t be present at the Conference with the entire team as we did last year.
For those who won’t be able to attend the miniLAC but can get a day trip, we have available some courtesy visitor one-day-passes to the Musikmesse. They are valid in any of the days form 7th to 10th.
If anyone is interested just let us know and we’ll manage a way to hand them over.
Best
Gianfranco Ceccolini
MOD Devices
+49 160 646 9313
gianfranco(a)moddevices.com
Dear miniLAC attendees,
we are very excited to announce our special guest for miniLAC2016:
Linus Torvalds, the creator of the Linux kernel and the awesome VCS git,
himself will attend to the weekend of workshops, lectures and hacking
sessions at c-base next weekend.
All the best and see you at the space station next week!
David
--
David Runge
Schreinerstraße 11
10247 Berlin
http://sleepmap.de