Open drewwells opened 9 years ago
What do you mean by "override g++ with mingw32"? On what platform?
On linux, you can get the windows.h headers for free by using mingw32 compiler ie. /usr/bin/i586-mingw32msvc-g++
I see. Is there any advantage to using that specific compiler over MinGW-w64? I know vanilla MinGW still doesn't support Windows XP APIs and newer (at least not fully). Right now, using -os windows
looks for MinGW-w64; in your case, it would be /usr/bin/i686-w64-mingw32-g++
.
I forget if I added $CC
and $CXX
override environment variables. If I didn't, I'll do so later.
Nope that works great, I didn't know how to activate mingw thanks!
I'm still confused why these headers are being loaded. https://github.com/sass/libsass/blob/master/file.cpp#L20-L22 guards the inclusion of the headers behind these sentinel flags, but qo includes them regardless of what -os I specify. Is there a piece I'm missing to build this?
Can you paste the output of qo -x
? That is, a native Linux build?
Sure can, Ubuntu 14.04 LTS
$ qo -x
[ 0%] Beginning build
gcc libsass-src/cencode.c -c --std=c99 -Wall -Wextra -Wno-unused-parameter -m64 -o .qoobj/libsass-src_cencode.c.o
g++ libsass-src/base64vlq.cpp -c --std=c++11 -Wall -Wextra -Wno-unused-parameter -m64 -o .qoobj/libsass-src_base64vlq.cpp.o
g++ libsass-src/ast.cpp -c --std=c++11 -Wall -Wextra -Wno-unused-parameter -m64 -o .qoobj/libsass-src_ast.cpp.o
gcc libsass-src/posix/getopt.c -c --std=c99 -Wall -Wextra -Wno-unused-parameter -m64 -o .qoobj/libsass-src_posix_getopt.c.o
g++ libsass-src/bind.cpp -c --std=c++11 -Wall -Wextra -Wno-unused-parameter -m64 -o .qoobj/libsass-src_bind.cpp.o
[ 1%] Compiled libsass-src/cencode.c
g++ libsass-src/constants.cpp -c --std=c++11 -Wall -Wextra -Wno-unused-parameter -m64 -o .qoobj/libsass-src_constants.cpp.o
libsass-src/posix/getopt.c:58:21: fatal error: windows.h: No such file or directory
#include <windows.h>
^
compilation terminated.
[FAIL] Step "Compiled libsass-src/posix/getopt.c" failed with error: exit status 1
It auto fails on OS X with llvm/clang message.
What happens if you put an #error before the second line of that file?
#ifdef _WIN32
#error _WIN32 defined here
#include <direct.h>
#define getcwd _getcwd
And what's the OS X error?
OS X auto dies with error about clang not supporting cross compilation.
-> % qo -os "darwin"
[FAIL] LLVM/clang does not come with a Windows resource compiler (if this message appears in other situations in error, contact andlabs)
You're trying to build a .rc file, which qo hardcodes to mean "Windows resource". What's your directory structure? Is this .rc file not a Windows resource? If I'm wrong I can fix it...
I think it's finding an rc file because qo scrapes the directory recursively. It appears the makefile specifies certain files to compile and other files are loaded conditionally based on architecture and other requirements. This makes building a little bit of a headache since you have to read the headers to figure out what files are necessary.
Is there perhaps, and I realize this is a lot to ask, a way to whitelist only certain files to be built? On Mon, Apr 20, 2015 at 9:15 PM Pietro Gagliardi notifications@github.com wrote:
You're trying to build a .rc file, which qo hardcodes to mean "Windows resource". What's your directory structure? Is this .rc file not a Windows resource? If I'm wrong I can fix it...
— Reply to this email directly or view it on GitHub https://github.com/andlabs/qo/issues/6#issuecomment-94614819.
Can't you just put it in the Windows folder?
As an example, these files are passed to g++: https://github.com/sass/libsass/blob/master/Makefile#L114-L153 and these headers are only passed when using MinGW: https://github.com/sass/libsass/blob/master/Makefile#L161-L172
The rc file in question (res/resource.rc
) is indeed a Windows resource file. I can definitely add conditional compilation in a similar way as the go tool does it, but libsass as it stands isn't compatible with qo's directory name expectations...
Ahh duh, go build
conventions! I'll rework the file structure and try again.
Another little caveat with a file.cpp:
file.cpp
#include <header.h>
Then a file structure like:
header.h
subdir/file.cpp
This is throwing errors with qo, but seems to work fine with libsass's make tools. Should this work as is?
No; what errors does it throw up? What is the difference between qo -x
and make
?
Glad you asked, that's what I've been looking at. https://gist.github.com/drewwells/5819cbba45ac6e0aa626
I moved more files around, then failed on
plugins.cpp:(.text+0xd1): undefined reference to `dlopen'
plugins.cpp:(.text+0xf1): undefined reference to `dlsym'
plugins.cpp:(.text+0x130): undefined reference to `dlsym'
plugins.cpp:(.text+0x187): undefined reference to `dlsym'
plugins.cpp:(.text+0x1de): undefined reference to `dlsym'
plugins.cpp:(.text+0x267): undefined reference to `dlerror'
plugins.cpp:(.text+0x29c): undefined reference to `dlclose'
plugins.cpp:(.text+0x2db): undefined reference to `dlerror'
This is resolved by passing -ldl
, how do you specify build flags?
// #qo LIBS: dl
Thanks that worked great! Is there anyway to specify ignoring certain files? IGNORE: contrib/
or similar?
@drewwells Not that I know of, though that would be a nice feature.
It would be nice to be able to override g++ with mingw32 for compiling windows specific headers.
This is useful for compiling windows specific headers that caused this error: