compiler failed on cygwin!

[LGTMCU]

build output:

g++ -fPIC -MMD -MP -Wall -O2 -std=c++11 -DPREFIX="/opt/riscv" -I. -I../fesvr -c ../fesvr/elfloader.cc
../fesvr/elfloader.cc:1:0: warning: -fPIC ignored for target (all code is position independent)
// See LICENSE for license details.
^
In file included from ../fesvr/memif.h:37:0,
from ../fesvr/elfloader.cc:9:
../fesvr/packet.h:27:15: error: conflicting declaration ‘typedef reg_t addr_t’
typedef reg_t addr_t;
^

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// here is my gcc details:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/5.3.0/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: /cygdrive/i/szsz/tmpp/gcc/gcc-5.3.0-5.i686/src/gcc-5.3.0/configure --srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-5.3.0-5.i686/src/gcc-5.3.0 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-arch=i686 --with-tune=generic --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp --enable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-libada --enable-libjava --enable-libgcj-sublibs --disable-java-awt --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible
Thread model: posix
gcc version 5.3.0 (GCC)

[aswaterman]

Supporting Cygwin hasn't been high on our priority list, but we'd of course be willing to review a compatibility patch.

[LGTMCU]

I will try to fixit. but infect, I am just run into linux programming world.
It seems easy to clean up type definition conflicting by given a more private name.
but while goes on, there comes another error which seems more confused to me:

---

../fesvr/syscall.cc: In member function ‘reg_t syscall_t::sys_openat(reg_t, reg_t, reg_t, reg_t, reg_t, reg_t, reg_t)’:
../fesvr/syscall.cc:217:101: error: ‘openat’ was not declared in this scope

(syscall(fds.lookup(fd), int(fd) == RISCV_AT_FDCWD ? do_chroot(name).c_str() : (name), VA_ARGS))

I have try to add "-I/usr/include" to compiler, where "fcntl.h" can be found.
But seems useless.
Can you help to give me some directions?

Thanks.

[madscientist42]

To call this "annoying" is putting it mildly. While I'm a hardcore Linux person (I'm part of the crowd that started the whole "Embedded Linux" craze decades ago...) not everybody can USE nothing but it. "Not high on our priority list" for something that's this important and you can't do this on a Windows system save via VM? Current client has me stuck on Windows only for company security policy reasons (And NO, there will be no convincing them otherwise...) and a VM's weak on this class of machine they've got as a normal desktop.

I'll look into what needs to be done to fix this...sigh...

[soberl]

for addr_t type, I made WAR like "typedef reg_t addr_t1; #define addr_t addr_t1" and revert including sequence in related .c files.
for missing lib functions like openat, I am not sure how to minimize the changes. Thinking.

[donggyukim]

I have a temporary solution for this, but not sure it'll meet your requirements:
https://github.com/firesim/riscv-fesvr/tree/windows

To handle addr_t, you can give -D__addr_t_defined to gcc.

[soberl]

@donggyukim, yes, that's very helpful, thanks a lot.
I was hesitate whether to look for third-part files that support openat...And your change looks straightforward and quite good.
I google and don't find desscription for usage of "-D__addr_t_defined". I see in .ii file, it's something like:
typedef reg_t addr_t; addr_t xxx; typedef char * addr_t;
How gcc deal with -D__addr_t_defined in this case?

[aswaterman]

I think the right way to solve this is to stop using the name addr_t in the global namespace. The __addr_t_defined workaround is brittle, as it assumes details of the Newlib header implementation.

We can probably fix this by moving it into the memif_t namespace. I'll look into it later.