It may be old news for seasoned programmers, but I found this to be a
trove of information that goes a bit beyond of the traditional wisdom of
"what's safe in a jack process() thread", so I thought I'd share it here
(courtesy of LWN's free subscriber link feature, please check out LWN!)
https://lwn.net/SubscriberLink/837019/e323ab1009054668/https://ogness.net/ese2020/ese2020_johnogness_rtchecklist.pdf
All best,
Jörn
--
Jörn Nettingsmeier
Tuinbouwstraat 180, 1097 ZB Amsterdam, Nederland
Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio), Tonmeister VDT
http://stackingdwarves.net
Hello all,
I'm having a strange problem with G++...
In one source file 'fb3data.cc', I define arrays like this:
const float svcoeff44 [216] =
{
1.631996e-03, 6.335480e-02, ...
...
};
There are five of these. In 'fbdata3.h' I have
extern const float svcoeff44 [216];
extern const float svcoeff48 [216];
extern const float svcoeff88 [216];
...
Finally in 'filtbank3.cc' there is
const float *c;
switch (fsam)
{
case 44100:
c = cvcoeff44;
break;
case 48000:
c = cvcoeff48;
break;
...
}
Everything compiles without errors or warnings, but the linking
step fails:
/usr/bin/ld: filtbank3.o: warning: relocation against `svcoeff88' in read-only section `.text'
/usr/bin/ld: filtbank3.o: in function `VocFiltbank::init(int)':
filtbank3.cc:(.text+0x159): undefined reference to `svcoeff192'
/usr/bin/ld: filtbank3.cc:(.text+0x1d3): undefined reference to `svcoeff48'
/usr/bin/ld: filtbank3.cc:(.text+0x1e3): undefined reference to `svcoeff96'
/usr/bin/ld: filtbank3.cc:(.text+0x1f3): undefined reference to `svcoeff44'
/usr/bin/ld: filtbank3.cc:(.text+0x1ff): undefined reference to `svcoeff88'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
collect2: error: ld returned 1 exit status
When I put the arrays in 'filtbank3.cc' instead, everything works.
Any hints ??
Ciao,
--
FA
Alexandre DENIS:
> On Mon, 16 Nov 2020 09:43:42 +0100
> Fons Adriaensen <fons(a)linuxaudio.org> wrote:
>
> > Hello all,
> >
> > I'm having a strange problem with G++...
> >
> > In one source file 'fb3data.cc', I define arrays like this:
> >
> > const float svcoeff44 [216] =
> > {
> > 1.631996e-03, 6.335480e-02, ...
> > ...
> > };
> >
> > (...)
> > /usr/bin/ld: filtbank3.o: warning: relocation against `svcoeff88'
> in
> > read-only section `.text'
>
> Hi,
>
> I've already seen this strange behavior with gcc 9.x : symbols with
> a const definition are by default not publicly visible. It works
> if you explicitly add an "extern" in the definition:
>
> extern const float svcoeff44 [216] = (...)
>
> I am not sure whether it is a bug in gcc or a strict application of the
> standard.
Yeah, I just read this: https://gcc.gnu.org/gcc-10/porting_to.html
"
C language issues
Default to -fno-common
A common mistake in C is omitting extern when declaring a global
variable in a header file. If the header is included by several files
it results in multiple definitions of the same variable. In previous
GCC versions this error is ignored. GCC 10 defaults to -fno-common,
which means a linker error will now be reported. To fix this, use
extern in header files when declaring global variables, and ensure
each global is defined in exactly one C file. If tentative definitions
of particular variables need to be placed in a common block,
__attribute__((__common__)) can be used to force that behavior even in
code compiled without -fcommon. As a workaround, legacy C code where
all tentative definitions should be placed into a common block can be
compiled with -fcommon.
int x; // tentative definition - avoid in header files
extern int y; // correct declaration in a header file
"
Guess that could explain it.
On Mon, Nov 16, 2020 at 12:59 PM Roman Sommer <roman.sommer(a)fau.de> wrote:
>
> Kjetil Matheussen <k.s.matheussen(a)gmail.com> writes:
> >
> > Yeah, I just read this: https://gcc.gnu.org/gcc-10/porting_to.html
> >
> > "
> >
> > C language issues
> >
> > Default to -fno-common
> >
> > A common mistake in C is omitting extern when declaring a global
> > variable in a header file. If the header is included by several files
> > it results in multiple definitions of the same variable. In previous
> > GCC versions this error is ignored. GCC 10 defaults to -fno-common,
> > which means a linker error will now be reported. To fix this, use
> > extern in header files when declaring global variables, and ensure
> > each global is defined in exactly one C file. If tentative definitions
> > of particular variables need to be placed in a common block,
> > __attribute__((__common__)) can be used to force that behavior even in
> > code compiled without -fcommon. As a workaround, legacy C code where
> > all tentative definitions should be placed into a common block can be
> > compiled with -fcommon.
> >
> > int x; // tentative definition - avoid in header files
> >
> > extern int y; // correct declaration in a header file
> > "
> >
> >
> > Guess that could explain it.
>
> Hm? Why would that explain this behaviour?
> It seems to me Fons already (correctly) uses "extern" in his header
Guess you're right. I didn't read the posts very thoroughly. That's
also why I wrote "could' and not "would".
Hello again,
This is the correct version:
(I typed this in manually instead of copy/paste...)
const float *c;
switch (fsam)
{
case 44100:
c = svcoeff44;
break;
case 48000:
c = svcoeff48;
break;
...
}
Ciao,
--
FA
Hello everybody,
On behalf of the LAC 2020 organization team we'd like to welcome you all to
LAC 2020 which due to the current confining situation in France will take
place via teleconferencing on Nov 25-27.
A Big Blue Button (BBB) instance, the teleconferencing software that we use,
has been set up for conducting the conference. We will follow up by
publishing the official link both by mail and on the conference website
<https://lac2020.sciencesconf.org/> when the conference starts.
Additionally, in case you cannot attend, note that all talks will be
recorded.
The programme is beinng finalized and is available here:
https://lac2020.sciencesconf.org/program
If you plan to attend, please take the time and register here:
https://lac2020.sciencesconf.org/registration
As usual, the conference can be attended free of charge.
We apologies for the delays in announcements
See you at LAC 2020!
