Hello llvmdev,
(just for fun) I've tried to compile LLVM under cygwin.
With "make -k" I got only:
Hi,
(just for fun) I've tried to compile LLVM under cygwin.
Thanks! This is very helpful.
As I think you implied, RTLD_{LAZY,NOW,GLOBAL} are not really handles
that can be passed to dlsym; rather, they're flags for dlopen.
For GetAddressOfSymbol() on Windows in general, it may be more appropriate to
reimplement it in terms of LoadLibrary()/GetProcAddress().
For GetAddressOfSymbol() on Cygwin in particular, which only partially
implements dlopen/dlsym, it may be OK to use the (nonstandard) call:
dlsym (dlopen (NULL, 0), symbolName).
/cygdrive/w/tmp/llvm/llvm/lib/Support/CommandLine.cpp:883: reloc
refers to symbol `.text$_ZNSt22_Rb_tree_base_iterator12_M_incrementEv'
which is not being output
This is a known bug in the cygwin version of "ld". I reported this to
the binutils maintainers in August and they have apparently fixed it
in mainline CVS:
http://sources.redhat.com/ml/binutils/2003-09/msg00013.html
http://sources.redhat.com/ml/binutils/2003-09/msg00025.html
http://sources.redhat.com/ml/binutils/2003-09/msg00040.html
However, a new version has not yet been released.
You may have better luck if you try the "ld" from current binutils CVS.
and the last issue was "etags: Unknown option: -l"
It looks like exuberant-ctags wants you to say
etags --language-force=c++ instead of etags -l c++
If you try any of these suggestions, please let us know how well they work.
Thanks again!
-Brian Gaeke
(just for fun) I've tried to compile LLVM under cygwin.
With "make -k" I got only:
Cool. We don't rountinely use this configuration, so there may be a bit
of leg work you'll have to do... 
But that said, we would love to get
LLVM working cleanly on it!
-----------------
DynamicLinker.cpp: In function `void* GetAddressOfSymbol(const char*)':
DynamicLinker.cpp:40: error: `RTLD_DEFAULT' undeclared (first use this
function)
DynamicLinker.cpp:40: error: (Each undeclared identifier is reported only once
for each function it appears in.)
-----------------well, the only value supported in cygwin's dlfcn.h are RTLD_LAZY,
RTLD_NOW and RTLD_GLOBAL.
Does the cygwin version of dlopen return the main process if 0 is passed
in as the first parameter? The wording in the linux man page looks like
this:
If filename is a NULL pointer, then the returned handle is for the
main program.
If so, this patch should fix the problem. Let me know if it helps:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20031020/008818.html
than compilation itself finished, just linkage failed with one screen
output!
The beginning of output is here (sorry if it is too much for this
maillist...) :
-------------------------------------
/cygdrive/w/tmp/llvm/llvm/lib/Support/Debug/CommandLine.o(.stab+0xce68): In function `GLOBAL__D__ZN2cl23ParseEnvironmentOptionsEPKcS1_S1_':
I believe that this is due to a known bug in the Cygwin linker. See this
thread:
http://sources.redhat.com/ml/binutils/2003-08/msg00218.html
If you upgrade to the latest and greatest, this may be fixed.
and the last issue was "etags: Unknown option: -l"
Remark:
---------------------------------
bash-2.05b$ etags.exe --version
Exuberant Ctags 5.5, Copyright (C) 1996-2003 Darren Hiebert
Compiled: Jun 5 2003, 10:00:19
Addresses: <dhiebert@users.sourceforge.net>, http://ctags.sourceforge.net
Optional compiled features: +wildcards, +regex, +internal-sort
---------------------------------
Interesting. The etags I have is part of emacs itself:
$ etags --version
etags (GNU Emacs 21.1.14)
Copyright (C) 1996 Free Software Foundation, Inc. and Ken Arnold
This program is distributed under the same terms as Emacs
The autoconf test for etags should not allow this version I guess. For
now, you can just comment out the 'ETAGS =' line in your top level
Makefile.config.
-Chris
Hello Chris and all,
Saturday, October 25, 2003, 7:17:28 PM, you wrote:
Cool. We don't rountinely use this configuration, so there may be a bit
of leg work you'll have to do...
LLVM working cleanly on it!
yes, it would be nice. Indeed that way LLVM could break into win32
world.
Does the cygwin version of dlopen return the main process if 0 is passed
in as the first parameter? The wording in the linux man page looks like
this:
...
If you upgrade to the latest and greatest, this may be fixed.
My goal was just to try compiling LLVM with cygwin. I'd like to wait
until next releases of cygwin instead of making my current up-to-date
stable cygwin release conflicting :-/