I am having trouble compiling C++ programs with wineg++. To illustrate my problem, I have written two test programs.
msgbox.cpp
#include <algorithm>
#include <iterator>
#include <cstdio>
#include <windows.h>
int APIENTRY WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
char buf[30], *pos = buf;
int xs[] = {1,3,2,4,3,5,4,6,5,7,6,8,7,9};
std::sort( std::begin(xs), std::end(xs) );
for (int x : xs) {
pos += std::sprintf(pos, "%d ", x);
}
MessageBox(0, buf, "Hello", 0);
return 0;
}
frame.cpp
#include "../win32xx/include/wxx_wincore.h"
#include "../win32xx/include/wxx_frame.h"
int APIENTRY WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
CWinApp winApp;
CFrame frame;
CWnd view;
frame.SetView(view);
frame.Create();
winApp.Run();
}
The second program uses the Win32++ library, which I can't recommend enough.
Both programs compile and run just fine using a cross-compiler:
okuu% x86_64-w64-mingw32-g++ msgbox.cpp -o msgbox.exe
okuu% wine ./msgbox.exe
okuu% x86_64-w64-mingw32-g++ frame.cpp -o frame.exe -lgdi32 -lcomctl32 -static
okuu% wine ./frame.exe
okuu% rm *exe*
But I want to use winelib so that I can use both the Windows API and Unix libraries. This is what I tried first:
okuu% wineg++ msgbox.cpp -o msgbox.exe
okuu% ./msgbox.exe
okuu% wineg++ frame.cpp -o frame.exe -mwindows
In file included from ../win32xx/include/wxx_appcore.h:57:0,
from ../win32xx/include/wxx_wincore.h:96,
from frame.cpp:1:
../win32xx/include/wxx_appcore0.h:120:12: fatal error: process.h: No such file or directory
#include <process.h>
^~~~~~~~~~~
compilation terminated.
winegcc: g++ failed
Then I read wineg++'s man page, which says:
-mno-cygwin
Use Wine implementation of MSVCRT, instead of linking against the host system libc. This is necessary for the vast majority of Win32 applications, as they typically depend on various features of MSVCRT. This switch is also used by the MinGW compiler to link against MSVCRT on Windows, instead of linking against Cygwin libc. Sharing the syntax with MinGW makes it very easy to write Makefiles that work under Wine, MinGW+MSYS, or MinGW+Cygwin.
So I tried again with -mno-cygwin, and got a 2000-line error message that begins with:
okuu% wineg++ frame.cpp -o frame.exe -mwindows -mno-cygwin
In file included from /usr/include/c++/7.2.1/cstdlib:75:0,
from /usr/include/c++/7.2.1/bits/stl_algo.h:59,
from /usr/include/c++/7.2.1/algorithm:62,
from ../win32xx/include/wxx_appcore0.h:110,
from ../win32xx/include/wxx_appcore.h:57,
from ../win32xx/include/wxx_wincore.h:96,
from frame.cpp:1:
/usr/include/stdlib.h:310:5: error: ‘int32_t’ does not name a type; did you mean ‘wint_t’?
int32_t *fptr; /* Front pointer. */
^~~~~~~
wint_t
/usr/include/stdlib.h:311:5: error: ‘int32_t’ does not name a type; did you mean ‘wint_t’?
int32_t *rptr; /* Rear pointer. */
^~~~~~~
wint_t
/usr/include/stdlib.h:312:5: error: ‘int32_t’ does not name a type; did you mean ‘wint_t’?
int32_t *state; /* Array of state values. */
^~~~~~~
wint_t
/usr/include/stdlib.h:316:5: error: ‘int32_t’ does not name a type; did you mean ‘wint_t’?
int32_t *end_ptr; /* Pointer behind state table. */
^~~~~~~
wint_t
/usr/include/stdlib.h:320:8: error: ‘int32_t’ has not been declared
int32_t *__restrict __result) __THROW __nonnull ((1, 2));
^~~~~~~
So it seems C99's fixed-size integer types are not available. That seems easy enough to solve:
frame.cpp
#include <stdint.h>
#include "../win32xx/include/wxx_wincore.h"
#include "../win32xx/include/wxx_frame.h"
// etc. etc. etc.
And I tried again, but got a different 2000-line error message that begins with:
okuu% wineg++ frame.cpp -o frame.exe -mwindows -mno-cygwin
In file included from /usr/include/c++/7.2.1/cwchar:44:0,
from /usr/include/c++/7.2.1/bits/postypes.h:40,
from /usr/include/c++/7.2.1/bits/char_traits.h:40,
from /usr/include/c++/7.2.1/string:40,
from ../win32xx/include/wxx_appcore0.h:111,
from ../win32xx/include/wxx_appcore.h:57,
from ../win32xx/include/wxx_wincore.h:96,
from frame.cpp:2:
/usr/local/include/wine/msvcrt/wchar.h:398:23: error: conflicting declaration of C function ‘size_t mbstowcs(wchar_t*, const char*, size_t)’
size_t __cdecl mbstowcs(wchar_t*,const char*,size_t);
^~~~~~~~
At this point I have run out of ideas. This is what I have understood so far:
My system's libc and Wine's MSVCRT have conflicting definitions. (This was probably to be expected.)
My system's libc++ is hardwired to work with my system's libc.
Wine comes with a MSVCRT, but not with a C++ standard library implementation.
The logical course of action with the information I have so far would be to look for a C++ standard library implementation that's compatible with Wine's MSVCRT, but I don't know of one. Does anybody here know of one?
The only solution I can think of is to stick with the system libc and write your own process.h. This file should either #include the standard header files that have the functions Win32++ needs or provide its own implementations of those functions. If Win32++ won't compile without a particular function but your program does not actually depend on that function, the implementation of that function can simply return 0 or another fake value.
If the system libc has a header file that Win32++ asks for, but the file does not declare all of the functions that Win32++ expects, you'll have to write a header file such as win32xx-compat.h that defines those functions and #include it before any Win32++ header.
Related
Im setting up the bsplib (https://github.com/Zefiros-Software/BSPLib) on a windows system (in VS Code) using WSL. When compiling I get the error message:
test.cpp:4:5: error: conflicting declaration of C function ‘int main()’
4 | int main()
| ^~~~
In file included from /mnt/d/study/software/bsp/include/bsp/bspExt.h:30,
from /mnt/d/study/software/bsp/include/bsp/bsp.h:34,
from test.cpp:2:
/mnt/d/study/software/bsp/include/bsp/bspClass.h:59:12: note: previous declaration ‘int main(int, char**)’
59 | extern int main(int argc, char **argv);
The program is used is just a bare example for BSP:
#include <iostream>
#include "bsp/bsp.h"
int main()
{
bsp_begin(bsp_nprocs());
int s = bsp_pid();
int p = bsp_nprocs();
printf("Hello World from processor %d / %d", s, p);
bsp_end();
return 0;
}
Compiled with:
g++ -I/mnt/d/study/software/bsp/include -g -lpthread -o main test.cpp
To my (quite limited) knowledge, the 'extern' in the header file should prevent the compiler from labelling the main as 'duplicate' of some sort. Im mostly interested in some of BSPs functionalities as part of a class of mine, that sadly does not include any support on the installation. What I've done so far:
Copied the include files from the repo
Added the include path to the compilation (-I Flag) and the -lpthread as instructed by the class script
Added the include path to the configuration (c_cpp_properties.json) [tested both with and without this, no difference]
Due to the many possible sources of that error (program, compiler, wsl, library, configuration, vs code, my stupidity) I cant determine where I am mistaken, nor am I able to find online resources to that combination.
I am struggling with a port of an open-source tool to Solaris. Most things work, cmake/pkg-config/etc. are there, dependencies are found, gmake works, compiler and linker calls look all fine and tren, boom:
Undefined first referenced
symbol in file
std::qsort(void*, unsigned int, unsigned int, int (*)(const void*, const void*)) ...
This part I don't understand. At the first glance, std::qsort does not make sense, it is supposed to be part of C library, not STL. So I looked into stdlib.h and found a list of things like using std::sort; and dozens of other standard functions like free, malloc, atoi, etc., redirected in case of C++ context.
What is Oracle doing there and why? Which library am I supposed to link with if they do redirect it like this? Or why does CC command not pull that in automatically like GCC does?
I tried adding -lstdc++ but no luck.
Alternatively, the plain libc versions seem to be defined in <iso/stdlib_c99.h> (or <iso/stdlib_iso.h>). Is it legal to include one of those headers directly or will this wreak other random havoc at link time?
Edit:
since there are multiple suspicions of the build system weirdness, here is the basically the linking call from the gmake execution:
/opt/developerstudio12.6/bin/CC -std=c++11 -xO3 -DNDEBUG <i.e. bunch of object files> -o ../systest -L/opt/csw/lib/64 -lintl
I cannot see anything special there and I expect CC to figure out what to link to get the obligatory functionality.
The rule is that #include <xxx.h> puts names into the global namespace and is allowed to also put them in std. Conversely, #include <cxxx> puts names into std and is allowed to also put them into the global namespace. In practice, this means that there are two approaches to implementing the functions from the standard C library in C++: declare the standard C library names in the <xxx.h> headers and hoist those declarations into std in the cxxx headers, or declare the names in std in the headers and hoist those declarations into the global namespace in the <xxx.h> headers. With the former approach, the name of the function will be qsort; with the latter, it will be std::qsort. Either way, that error message usually indicates a setup problem with the compiler. The linker isn’t finding the standard library.
This compile command
/opt/developerstudio12.6/bin/CC -std=c++11 -xO3 -DNDEBUG ...
will produce a 32-bit executable. Per the Oracle CC man page:
On Oracle Solaris, -m32 is the default. On Linux systems supporting 64-bit programs, -m64 -xarch=sse2 is the default.
But this library option
-L/opt/csw/lib/64
is searching a directory full of 64-bit libraries.
Either add -m64 to the compile command or use the 32-bit library path.
Update
The question almost certainly would be answerable had it included the full error message, which is almost certainly something like this:
CC -g qsort.cc -o qsort
"qsort.cc", line 15: Error: Could not find a match for std::qsort(int[4], unsigned, unsigned, int(void*,void*)) needed in main(int, char**).
"/usr/include/iso/stdlib_iso.h", line 184: Note: Candidate 'std::qsort(void*, unsigned, unsigned, extern "C" int(*)(const void*,const void*))' is not viable: argument '4' can't be converted from 'int(void*,void*)' to 'extern "C" int(*)(const void*,const void*)'.
"/usr/include/iso/stdlib_iso.h", line 187: Note: Candidate 'std::qsort(void*, unsigned, unsigned, int(*)(const void*,const void*))' is not viable: argument '4' can't be converted from 'int(void*,void*)' to 'int(*)(const void*,const void*)'.
This code works just fine when compiled with Oracle Developer Studio 12.6 on Solaris 11.4:
#include <stdlib.h>
int compare( const void *p1, const void *p2 )
{
int i1 = *( ( int * ) p1 );
int i2 = *( ( int * ) p2 );
return( i1 - i2 );
}
int main( int argc, char **argv )
{
int array[ 4 ] = { 5, 8, 12, 4 };
qsort( array, sizeof( array ) / sizeof( array[ 0 ] ),
sizeof( array[ 0 ] ), &compare );
}
I am trying to run SVD from the Eigen library with MKL but get the following errors
In file included from blas_mkl.cpp:6:
In file included from /usr/local/include/eigen3/Eigen/SVD:11:
In file included from /usr/local/include/eigen3/Eigen/QR:45:
/usr/local/include/eigen3/Eigen/src/QR/ColPivHouseholderQR_LAPACKE.h:85:1: error: cannot initialize a variable of type 'long long *' with an rvalue of type
'Eigen::PlainObjectBase<Eigen::Matrix<int, -1, 1, 0, -1, 1> >::Scalar *' (aka 'int *')
EIGEN_LAPACKE_QR_COLPIV(double, double, d, ColMajor, LAPACK_COL_MAJOR)
...
/usr/local/include/eigen3/Eigen/src/QR/ColPivHouseholderQR_LAPACKE.h:74:15: note: expanded from macro 'EIGEN_LAPACKE_QR_COLPIV'
lapack_int *perm = m_colsPermutation.indices().data(); \
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
8 errors generated.
I have the latest version of MKL, and my cpp file is
//blas_mkl.cpp
#define EIGEN_USE_MKL_VML
#define EIGEN_USE_LAPACKE
#include <iostream>
#include <eigen3/Eigen/Core>
#include <eigen3/Eigen/SVD>
using namespace Eigen;
using namespace std;
int main() {
MatrixXf data(4, 2);
data << 76, 8,
0, 0,
82, 3,
80, 0;
JacobiSVD<MatrixXf> svd(data, ComputeThinU | ComputeThinV);
cout << svd.matrixU() * svd.singularValues().asDiagonal() * svd.matrixV().transpose() << endl;
cout << data << endl;
return 0;
}
and I use the following command to run the code
g++ -DMKL_ILP64 -m64 -I${MKLROOT}/include ${MKLROOT}/lib/libmkl_intel_ilp64.a ${MKLROOT}/lib/libmkl_intel_thread.a ${MKLROOT}/lib/libmkl_core.a -liomp5 -lpthread -lm -ldl -o blas_mkl blas_mkl.cpp
where echo ${MKLROOT} gives
/opt/intel/compilers_and_libraries_2020.2.258/mac/mkl
But the code actually works fine when I keep only #define EIGEN_USE_MKL_VML, but I get segmentation fault 11 when I keep the LAPACKE. Can someone tell me what's going on here?
I see the option -DMKL_ILP64 in your command line. Under ILP64, MKL_INT and lapack_int are type aliases for long long, under LP64 they are aliases for int. Hence, the error message (though it is not clear how it is related to a segfault): you can't assign int* to long long*. But the Eigen documentation states that only LP64 is supported (emphasis is mine):
Using Intel MKL through Eigen is easy:
define the EIGEN_USE_MKL_ALL macro before including any Eigen's header, link your program to MKL libraries (see the MKL linking advisor), on a 64bits system, you must use the LP64 interface (not the ILP64 one).
Try to remove -DMKL_ILP64 flag and link against LP64 library version.
Can cygwin make use of gettimeofday()? I'm getting the error:
lab8.cpp: In function ‘int main()’:
lab8.cpp:62:30: error: ‘gettimeofday’ was not declared in this scope
gettimeofday(&start, NULL);
^
makefile:14: recipe for target 'lab8.o' failed
make: *** [lab8.o] Error 1
I definitely included <sys/time.h>. Is there a package that I have to install or does it just not work on Windows?
EDIT: Here's a simple test that yields the same error:
#include <sys/time.h>
int main() {
struct timeval start;
gettimeofday(&start, NULL);
}
With the error:
$ g++ -c -Wall -g -std=c++11 test.cpp -o test.o
test.cpp: In function ‘int main()’:
test.cpp:6:30: error: ‘gettimeofday’ was not declared in this scope
gettimeofday(&start, NULL);
You need to define _BSD_SOURCE to include the declaration gettimeofday (since glibc2.2.2 according to link below)
#define _BSD_SOURCE
#include <sys/time.h>
int main() {
struct timeval start;
gettimeofday(&start, NULL);
}
gettimeofday() - Unix, Linux System Call
Thank you John - your question game me my answer!
In case it helps anyone else searching on this error...
I got the same error:
error: ‘gettimeofday’ was not declared in this scope
gettimeofday(&lastBigTick, NULL);
This error started happening when I moved from Debian 8 (jessie) to Debian 9 (stretch) on a raspberry pi
For me, I had NOT #included "sys/time.h" I had only #included "time.h"
Not sure how it compiled before, but it did, so adding
#include "sys/time.h"
did the job for me.
Note: "time.h" is different and is still needed for other time functions, so I ended up needing both:
#include "time.h"
#include "sys/time.h"
My situation was perhaps different, as adding
#define _BSD_SOURCE
made no difference in my case - ie this was not the issue for me.
I am writing an application to test whether pbs_connect() is working or not. Here is my code:
#include <stdio.h>
#include "/usr/include/torque/pbs_ifl.h"
#include "/usr/include/torque/pbs_error.h"
#include <pbs_config.h>
#include "libpbs.h"
int main() {
printf("Hello world\n");
int server = pbs_connect("inferno.local");
//batch_status * stat1 = pbs_statserver(server, NULL, NULL);
pbs_errno = 0;
batch_status * stat1 = PBSD_status(server, 21, (char *)"", NULL, NULL);
printf("fd: %d\n", server);
//printf("text: %s\n", stat1->text);
//printf("name: %s\n", stat1->name);
printf("name: %d\n", pbs_errno);
return 0;
}
//compiled using - //g++ -o test test.c -L/usr/lib64 -ltorque
I get:
# g++ -o test test.c -L/usr/lib64 -ltorque
test.c:7:24: error: pbs_config.h: No such file or directory
test.c:8:20: error: libpbs.h: No such file or directory
test.c: In function 'int main()':
test.c:19: warning: deprecated conversion from string constant to 'char*'
test.c:24: error: 'PBSD_status' was not declared in this scope
The source file that contains PBSD_status can be found here:
https://github.com/adaptivecomputing/torque/blob/4.2.7/src/lib/Libifl/PBSD_status.c
Is there something i need to include in my g++ command to get this to work? I have checked in /usr/lib64/, and there is no libpbs.h or pbs_config.h. Where would they be, if they aren't there?
As far as your headers, you're running into the difference between installed and not installed headers. Essentially, a software project doesn't install every header inside that project, only relevant ones for the API. These other two aren't in the API and therefore aren't installed. You need to reference their path.
As far as including PBSD_status() in the library, you could edit the Makefile for Libpbs to include the source file for PBSD_status() and then rebuild, or you could link to the libifl library, which is in src/lib/Libifl from the base directory for the project.