Mail Archives: djgpp-workers/2004/01/08/03:10:50
There is one problem with DJGPP port of GCC-3.3.2, which perhaps nobody has
noticed (or at least reported, as I don't remember it mentioned in mailing
list)
Linking of C++ program with gpp.exe links with libstdc++.a instead of
libstdcxx.a when profiling is enabled (option -pg is specified). It can be
fixed by adding one line to gcc/config/i386/djgpp.h
#define LIBSTDCXX_PROFILE "-lstdcxx"
But perhaps definitions of LIBSTDCXX and LIBSTDCXX_PROFILE should be
moved to gcc/config/i386/xm-djgpp.h from djgpp.h, as there is no special
reason to rename library for DJGPP targeted cross-compiler.
I have build with missing #define added to djgpp.h. (also update to
config.sub to be able to specify --target=djgpp, instead of renaming target
related directories later):
--- config.sub.orig 2003-01-30 23:25:36.000000000 +0000
+++ config.sub 2004-01-03 14:43:26.000000000 +0000
@@ -458,6 +458,10 @@
basic_machine=m88k-motorola
os=-sysv3
;;
+ djgpp)
+ basic_machine=i586-pc
+ os=-msdosdjgpp
+ ;;
dpx20 | dpx20-*)
basic_machine=rs6000-bull
os=-bosx
Andris
PS. Tried to build gcc-3.3.2, one development version of gcc-3.4, etc on
Windows XP machine when was in Christmass and New Year holydays in Latvia.
It was almost a nightmare, even if I tried to use binaries from clio.rice.edu
(I used fresh build of djdev204 beta from sources)
1) find.exe from clio.rice.edu was broken, but rebuilding helped.
2) got strange error messages like 'sources are in directory foo, but cd foo
does not work', when foo was DOS absolute path without drive letter.
Workarounded that by editting Makefile to add /dev/c at start of path.
Unfortunatelly that happens in rather specific situation when cd fails with
ENOENT, but I was not able to find an simple example where it happens.
One package which has this problem was GDB-6.0 (configure in directory
libiberty run from toplevel make fails with that error at least if source
directory is different from build directory)
- Raw text -