excompiler.cpp: unistd.h
Hi, #include <unistd.h> trips up compilation with MSVC. Is it really required? I commented it out and the file compiled anyway. Also, configure.ac checks for unistd.h, and reports it is not there on Windows. Shouldn't excompiler.cpp make use of that information? Greetings, Jan
Hi Jan, On 11/01/2016 09:59 PM, Jan Rheinländer wrote:
#include <unistd.h> trips up compilation with MSVC. Is it really required? I commented it out and the file compiled anyway.
Where is the close() function declared, if not in <unistd.h>?
Also, configure.ac checks for unistd.h, and reports it is not there on Windows. Shouldn't excompiler.cpp make use of that information?
Yes it should. -richy. -- Richard B. Kreckel <http://in.terlu.de/~kreckel/>
Hi Richard,
Hi Jan,
On 11/01/2016 09:59 PM, Jan Rheinländer wrote:
#include <unistd.h> trips up compilation with MSVC. Is it really required? I commented it out and the file compiled anyway. Where is the close() function declared, if not in <unistd.h>?
good question - but as I said, if I just comment out <unistd.h> it compiles on MSVC and all checks pass successfully. So maybe it needs a conditional: #ifndef _MSC_VER #include <unistd.h> #endif
Hi Jan, On 11/03/2016 12:13 PM, Jan Rheinländer wrote:
On 11/01/2016 09:59 PM, Jan Rheinländer wrote:
#include <unistd.h> trips up compilation with MSVC. Is it really required? I commented it out and the file compiled anyway. Where is the close() function declared, if not in <unistd.h>?
good question - but as I said, if I just comment out <unistd.h> it compiles on MSVC and all checks pass successfully. So maybe it needs a conditional:
Can you, please, try to find out where close() comes from on your system? -richy. -- Richard B. Kreckel <http://in.terlu.de/~kreckel/>
Hi Richard,
On 11/03/2016 12:13 PM, Jan Rheinländer wrote:
On 11/01/2016 09:59 PM, Jan Rheinländer wrote:
#include <unistd.h> trips up compilation with MSVC. Is it really required? I commented it out and the file compiled anyway. Where is the close() function declared, if not in <unistd.h>? good question - but as I said, if I just comment out <unistd.h> it compiles on MSVC and all checks pass successfully. So maybe it needs a conditional: Can you, please, try to find out where close() comes from on your system?
-richy. it's defined in <corecrt_io.h> which in turn is included by <io.h>
Jan
Hi Jan, On 11/03/2016 09:14 PM, Jan Rheinländer wrote:
On 11/03/2016 12:13 PM, Jan Rheinländer wrote:
On 11/01/2016 09:59 PM, Jan Rheinländer wrote:
#include <unistd.h> trips up compilation with MSVC. Is it really required? I commented it out and the file compiled anyway. Where is the close() function declared, if not in <unistd.h>? good question - but as I said, if I just comment out <unistd.h> it compiles on MSVC and all checks pass successfully. So maybe it needs a conditional: Can you, please, try to find out where close() comes from on your system?
-richy. it's defined in <corecrt_io.h> which in turn is included by <io.h>
Interesting. And which header includes <io.h>? (I'm sure you don't mean <cln/io.h>.) -richy. -- Richard B. Kreckel <http://in.terlu.de/~kreckel/>
Hi Jan,
On 11/03/2016 09:14 PM, Jan Rheinländer wrote:
On 11/03/2016 12:13 PM, Jan Rheinländer wrote:
On 11/01/2016 09:59 PM, Jan Rheinländer wrote:
#include <unistd.h> trips up compilation with MSVC. Is it really required? I commented it out and the file compiled anyway. Where is the close() function declared, if not in <unistd.h>? good question - but as I said, if I just comment out <unistd.h> it compiles on MSVC and all checks pass successfully. So maybe it needs a conditional: Can you, please, try to find out where close() comes from on your system?
-richy. it's defined in <corecrt_io.h> which in turn is included by <io.h> Interesting. And which header includes <io.h>? (I'm sure you don't mean <cln/io.h>.) I can't really find anything. Maybe autoconf does some magic? Because in
Hi Richard, libtool and ltmain.sh it says: #ifdef _MSC_VER # include <direct.h> # include <process.h> # include <io.h> #else # include <unistd.h> # include <stdint.h> # ifdef __CYGWIN__ # include <io.h> # endif #endif Jan
Hi Jan, On 11/04/2016 07:56 PM, Jan Rheinländer wrote:
it's defined in <corecrt_io.h> which in turn is included by <io.h> Interesting. And which header includes <io.h>? (I'm sure you don't mean <cln/io.h>.) I can't really find anything. Maybe autoconf does some magic? Because in libtool and ltmain.sh it says:
#ifdef _MSC_VER # include <direct.h> # include <process.h> # include <io.h> #else # include <unistd.h> # include <stdint.h> # ifdef __CYGWIN__ # include <io.h> # endif #endif
I see. And thanks for your patience. Does the attached patch work, then? -richy. -- Richard B. Kreckel <http://in.terlu.de/~kreckel/>
Hi Richard,
Hi Jan,
On 11/04/2016 07:56 PM, Jan Rheinländer wrote:
it's defined in <corecrt_io.h> which in turn is included by <io.h> Interesting. And which header includes <io.h>? (I'm sure you don't mean <cln/io.h>.) I can't really find anything. Maybe autoconf does some magic? Because in libtool and ltmain.sh it says:
#ifdef _MSC_VER # include <direct.h> # include <process.h> # include <io.h> #else # include <unistd.h> # include <stdint.h> # ifdef __CYGWIN__ # include <io.h> # endif #endif I see. And thanks for your patience. Does the attached patch work, then? yes, everything compiles fine and all checks pass.
Jan P.S. In numeric.cpp line 445 the compiler warns about the usage of bool in the comparison if (cln::plusp(x) > 0) since plusp() returns a bool value.
participants (2)
-
Jan Rheinländer
-
Richard B. Kreckel