Re: [LAD] G++ trouble
On Mon, 16 Nov 2020 13:38:01 + Will J Godfrey wrote: > Not wishing to hijack this thread but I'm still confused :( > > I just did a search of the whole of src. It's *used* about a dozen > times across 5 otherwise unrelated .cpp files, but is only defined > here. Just to be certain, I did a make clean before trying this > again, and it's definitely saying multiple defs > > e.g > /usr/bin/ld: > CMakeFiles/yoshimi.dir/UI/WidgetMWSlider.cpp.o:(.rodata+0x0): > multiple definition of `ADD_COLOUR'; > CMakeFiles/yoshimi.dir/Interface/InterChange.cpp.o:(.rodata+0x1840): > first defined here > > This happens at the linker stage. > > Also, I thought the whole idea of putting things like this in a > #ifndef/#def block was to ensure it was only set once. > It is only set once *per file* which includes the header. But since the symbol is extern, the linker sees one public copy per file, which conflict with each other. -a. pgpgkvYhUvSN1.pgp Description: OpenPGP digital signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] G++ trouble
On Mon, 16 Nov 2020 09:43:42 +0100
Fons Adriaensen 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.
-a.
pgp1qeiE83ZDt.pgp
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Jack midi sequencer, threading and shared state
On Mon, 16 Sep 2013 18:34:17 -0600 Burkhard Ritter burkh...@ualberta.ca wrote: My understanding now is that: 1. Atomicity (meaning atomic read and write) in and by itself is not enough. I also need to ensure that memory access does not get reordered across my atomic reads and writes (so that, for example, I don't happen to increase the write counter before the data is actually written to the buffer). 2. To ensure atomicity and to enforce these memory barriers I always need some (cpu/architecture specific) special instructions. Hi, For atomic read/writes, barriers, and other atomic operations, cpu-specific instructions are not needed anymore. You can use generic gcc builtins: http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Atomic-Builtins.html -Alexandre. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
