Mail Archives: cygwin/2001/01/31/02:06:51
Today, Christopher Faylor wrote:
> - Looks in /usr/lib/mingw for mingw libraries.
I suspect i'm not fully understanding this part, either that
or the top level answer to my last question on the list is
"it ain't quite there yet."
I've tried with two different contents in /usr/lib/mingw/
first off the files that were there to begin with in a
current Cygwin installation (mingw-20001225-1) and with
a compile command as such:
g++ -mno-cygwin -DHAVE_CONFIG_H -I. -I../../jikes/src -c -o
ast.o ../../jikes/src/ast.cpp
but that's no different than what I had in November:
In file included from
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7/../../../../include/g++-3/streambuf.h:36,
from
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7/../../../../include/g++-3/iostream.h:31,
from ../../jikes/src/platform.h:113,
from ../../jikes/src/ast.h:14,
from ../../jikes/src/ast.cpp:11:
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7/../../../../include/g++-3/libio.h:30: _G_config.h: No
such file or directory
make: *** [ast.o] Error 1
So I tried it with -mwin32 added in as well... no difference, but then I
wasn't expecting much yet, because i remember Earnie specfically talking
about having to have different libraries.
Next I tried using the lib and include files from the mingw snapshot I've
been using... happiness is. It churned along for the better part of an
hour, but finally completed compiling all our parts then the linker kicked
in as such:
g++ -mno-cygwin -g -O2 -o jikes.exe ast.o body.o bytecode.o case.o
code.o control.o decl.o definite.o depend.o diagnose.o double
.o dump.o error.o expr.o getclass.o incrmnt.o init.o javaact.o jikes.o
jikesapi.o long.o lookup.o lpginput.o modifier.o op.o option.
o parser.o scanner.o segment.o set.o stream.o symbol.o system.o tab.o
unparse.o unzip.o zip.o platform.o
it thought about it for quite a while... then disaster:
/usr/lib/libstdc++.a(iostream.o)(.text+0x14c):iostream.cc: undefined
reference to `_imp___ctype_'
(... 20 more of these from other places than iostream ...)
I suspected I missed something in the configuration related to the
linkage step. That's the *wrong* version of libstdc++.a. I'm fairly
certain that I have the "right" one in /usr/local/mingw/lib/gcc-lib/
i386-mingw32msvc/2.95.2/libstdc++.a but where should I put it that
the standard linker pass will pick it up? /usr/lib/mingw/ ? yup.
The linkage stage now works like a charm, the resulting binary runs
and ... the acid test:
/jikes/cvs/mingwbld/src $ cygcheck ./jikes.exe
./jikes.exe
D:\WINNT\System32\KERNEL32.dll
D:\WINNT\System32\ntdll.dll
D:\WINNT\System32\msvcrt.dll
<gbg>
So with this build of gcc, the current snapshot lib and include, and
libstdc++.a stolen from mingw I have now compiled C++ code using the
STL with -mno-cygwin ... and it works.
I guess then the question is why there's a difference between the
current mingw tarball in cygwin and the libs in the snapshot? Is
there supposed to be? I'm not familiar enough with the cygwin
packaging of mingw to know.
(in hindsight I should probably go redo the top of this note...
but I'm going to bed, g'night y'all.)
--
now the forces of openness have a powerful and
unexpected new ally - http://ibm.com/linux
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -