Not sure if this is me or not, because this is the first time I've built LLVM on Cygwin, but I can't get a working compile. I've configured with the following options:
Configure doesn't suggest there's anything wrong, but when I try make, I almost immediately get the following error:
make[1]: Entering directory `/cygdrive/i/Projects/llvm/lib/System'
llvm[1]: Compiling Path.cpp for Debug build
In file included from Path.cpp:201:
Unix/Path.inc: In static member function `static llvm::sys::Path llvm::sys::Path::GetMainExecutable(const char*, void*)':
Unix/Path.inc:256: error: `Dl_info' undeclared (first use this function)
Unix/Path.inc:256: error: (Each undeclared identifier is reported only once for each function it appears in.)
Unix/Path.inc:256: error: expected `;' before "DLInfo"
Unix/Path.inc:257: error: `DLInfo' undeclared (first use this function)
Unix/Path.inc:257: error: `dladdr' undeclared (first use this function)
make[1]: *** [/cygdrive/i/Projects/llvm/lib/System/Debug/Path.o] Error 1
make[1]: Leaving directory `/cygdrive/i/Projects/llvm/lib/System'
make: *** [all] Error 1
I have svn revision 48243, a relatively recent cygwin (1.5.24-2) with gcc 3.4.4 (i.e. not the 3.3.3 version described in the docs as not working), and WinXP.
Not sure if this is me or not, because this is the first time I've built
LLVM on Cygwin, but I can't get a working compile.
Last I checked, LLVM-on-Cygwin has at least two problems, and you've hit
one of them. Working around them isn't too bad, though patches to fix
them would be appreciated.
llvm::sys::Path::GetMainExecutable(const char*, void*)':
Unix/Path.inc:256: error: `Dl_info' undeclared (first use this function)
Unix/Path.inc:256: error: (Each undeclared identifier is reported only
once for each function it appears in.)
Unix/Path.inc:256: error: expected `;' before "DLInfo"
Unix/Path.inc:257: error: `DLInfo' undeclared (first use this function)
Unix/Path.inc:257: error: `dladdr' undeclared (first use this function)
...
Any ideas?
What LLVM is trying to do here is determine its own path. I don't know
if the approach being used will work on Cygwin. (The code is very new,
and it's never worked on Cygwin.) You could try reading the
/proc/$$/exe symlink. I don't know how long Cygwin has been emulating
/proc, though.
Once you get past that, the other build errors you'll get will be due to
code assuming that uint32_t is typedefed to int. On 32-bit Cygwin, it's
typedefed to long. (They're the same size, but it still confuses the
compiler.) This is an on-going problem, and I only use Cygwin in a
pinch, so I've just modified the 32-bit typedefs in my
/usr/include/stdint.h file. I've chosen to fight other battles.
What LLVM is trying to do here is determine its own path. I don't know
if the approach being used will work on Cygwin. (The code is very new,
and it's never worked on Cygwin.) You could try reading the
/proc/$$/exe symlink. I don't know how long Cygwin has been emulating
/proc, though.
The dladdr() code won't work on Cygwin; the function isn't available. However, I've attached a (tested) patch which implements the /proc/$$/exe approach.
Once you get past that, the other build errors you'll get will be due to
code assuming that uint32_t is typedefed to int. On 32-bit Cygwin, it's
typedefed to long. (They're the same size, but it still confuses the
compiler.) This is an on-going problem, and I only use Cygwin in a
pinch, so I've just modified the 32-bit typedefs in my
/usr/include/stdint.h file. I've chosen to fight other battles.
LLVM compiles fine with my stdint.h changes, for what that's worth.
Once you get past that, the other build errors you'll get will be due to
code assuming that uint32_t is typedefed to int. On 32-bit Cygwin, it's
typedefed to long. (They're the same size, but it still confuses the
compiler.) This is an on-going problem, and I only use Cygwin in a
pinch, so I've just modified the 32-bit typedefs in my
/usr/include/stdint.h file. I've chosen to fight other battles.
I think I'm with you. It's not like I can't run a Linux virtual machine on this hardware.
Please attach patches as attachments (and name the file ".patch" just in case). Mail readers commonly munge them (e.g. by removing trailing whitespace) if not, which prevents the patch from applying.
Please attach patches as attachments (and name the file
".patch" just in case). Mail readers commonly munge them
(e.g. by removing trailing whitespace) if not, which prevents
the patch from applying.
I hope that this is not off-topic, but why is this?
I'm doing some amount of linux-driver kernel work, and there you
are urged to insert your patch directly into the body, not as an
attachment. What you have to do is to disable word-wrapping.
The various kernel subsystem maintainers then directly put the
patches from their mailclients into git, and trailing whitespace
doesn't seem to be a problem there.
The benefit is that various web-based mailing list archives have
the code snippets there directly, so they end up eventually in
google. You can also much better comment on those patches,
replying and writing your stuff in-between.
For reference, here's an excerpt from
linux/Documentation/SubmittingPatches:
If you name the file *.txt, various mail clients inline the contents of the file implicitly when it sends it.
The reason for including it as an attachment is that various *other* mail readers trim whitespace when they receive/display it. Word wrapping is another problem.
In any case, attachments make all this trivial to deal with, which is why we prefer them.
