[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Woe with doSetUnset
From: |
john o goyo |
Subject: |
Re: Woe with doSetUnset |
Date: |
Mon, 4 Jul 2022 09:46:54 -0400 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 |
On 2022-07-03 12:36, Gaius Mulley wrote:
john o goyo<jog37@riddermarkfarm.ca> writes:
<jog37@riddermarkfarm.ca> wrote:
Gaius:
I will not be setting up my Sparc box for another few weeks,
so I am
concentrating on mc. To obtain the required header files, I
am building
a cross-compiler on my M1 Mini for aarch64-unknown-freebsd10.1
and
encountering a strange error.
/usr/bin/g++ -std=gnu++11 -DHAVE_CONFIG_H -g -c -I. -Im2/gm2-libs
-I../../../src/gcc-git-devel-modula2/gcc/../include
-I../../../src/gcc-git-devel-modula2/gcc -I. -Im2/mc-boot-ch
-I../../../src/gcc-git-devel-modula2/gcc
-I../../../src/gcc-git-devel-modula2/gcc/m2/mc-boot-ch
-I../../../src/gcc-git-devel-modula2/gcc/../include
-I../../../src/gcc-git-devel-modula2/gcc/../libcpp/include
-I../../../src/gcc-git-devel-modula2/gcc/../libcody
-I/usr/local/include
-I/usr/local/include -I/usr/local/include
-I../../../src/gcc-git-devel-modula2/gcc/../libdecnumber
-I../../../src/gcc-git-devel-modula2/gcc/../libdecnumber/bid
-I../libdecnumber
-I../../../src/gcc-git-devel-modula2/gcc/../libbacktrace
-Im2/gm2-libs
../../../src/gcc-git-devel-modula2/gcc/m2/mc-boot-ch/Gtermios.c
-o
m2/mc-boot-ch/Gtermios.o
clang: warning: treating 'c' input as 'c++' when in C++ mode,
this
behavior is deprecated [-Wdeprecated]
../../../src/gcc-git-devel-modula2/gcc/m2/mc-boot-ch/Gtermios.c:1103:14:
error: no matching function for call to 'doSetUnset'
return doSetUnset (&t->c_iflag, IGNBRK, b);
But doSetUnset is defined at ll. 394+ in the same file Gtermios.c.
I am somewhat stumped by this one.
john
Greetings, Gaius.
No joy -- I removed EXTERN and the error results.
Sincerely,
john
Hi John,
very odd - I've made the following changes on my debian box with clang:
clang++ --version
Debian clang version 11.0.1-2
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
and it now compiles without any warnings with g++ and also clang++.
Here is the complete source file - I had to rename it to .cc (to get
rid of the c c++ deprecated warning).
I also had to change the appropriate build rule in gcc/m2/Make-lang.in.
I'll git commit/git push the changes tomorrow (on devel/m2link). It
would be interesting to see if this works on the m1?
Same error:
/usr/bin/g++ -std=gnu++11 -DHAVE_CONFIG_H -g -c -I. -Im2/gm2-libs
-I../../../src/gcc-git-devel-modula2/gcc/../include
-I../../../src/gcc-git-devel-modula2/gcc -I. -Im2/mc-boot-ch
-I../../../src/gcc-git-devel-modula2/gcc
-I../../../src/gcc-git-devel-modula2/gcc/m2/mc-boot-ch
-I../../../src/gcc-git-devel-modula2/gcc/../include
-I../../../src/gcc-git-devel-modula2/gcc/../libcpp/include
-I../../../src/gcc-git-devel-modula2/gcc/../libcody -I/usr/local/include
-I/usr/local/include -I/usr/local/include
-I../../../src/gcc-git-devel-modula2/gcc/../libdecnumber
-I../../../src/gcc-git-devel-modula2/gcc/../libdecnumber/bid
-I../libdecnumber
-I../../../src/gcc-git-devel-modula2/gcc/../libbacktrace -Im2/gm2-libs
../../../src/gcc-git-devel-modula2/gcc/m2/mc-boot-ch/Gtermios.c -o
m2/mc-boot-ch/Gtermios.o
clang: warning: treating 'c' input as 'c++' when in C++ mode, this
behavior is deprecated [-Wdeprecated]
../../../src/gcc-git-devel-modula2/gcc/m2/mc-boot-ch/Gtermios.c:1091:14:
error: no matching function for call to 'doSetUnset'
return doSetUnset (&t->c_iflag, IGNBRK, b);
^~~~~~~~~~
../../../src/gcc-git-devel-modula2/gcc/m2/mc-boot-ch/Gtermios.c:168:1:
note: candidate function not viable: no known conversion from 'tcflag_t
*' (aka 'unsigned long *') to 'unsigned int *' for 1st argument
doSetUnset (unsigned int *bitset, unsigned int mask, int value)
[Plus 30 more ...]
But the note above speaks of conversion. I changed the first argument
to "unsigned long *" and the build continued until encountering the same
at gcc/m2/gm2-libs-ch/termios.c.
Of course, the build stopped at building shared objects because I do not
have the cross-compilation binutils. Nevertheless, I now have the
header files.
Sincerely,
john
regards,
Gaius