On Mar 13 23:24, Yaakov (Cygwin/X) wrote:
> On Sun, 2011-03-13 at 12:36 +0100, Corinna Vinschen wrote:
> > this offer is way cool. Thanks for doing this, because this allows my lazy
> > self to switch to the latest gcc to build Cygwin without having to build
> > the compiler and all the stuff myself. Really cool.
>
> Glad to help.
>
> > I've just tested to build Cygwin with this gcc, and I have only two small
> > problems:
> >
> > - libbfd.a and the bfd.h header have to be manually installed, otherwise
> > I can't build dumper.exe. It would be nice to get a minimal cygwin-bfd
> > runtime package as well to support my lazyness even more. :)
>
> I just added a cygwin-binutils-devel package with the necessary headers
> and static libraries.
>
> The only trick is you need to manually
> remove /usr/i686-pc-cygwin/lib/libiberty.a so that the "correct"
> libiberty.a is used instead until I have the chance to rebuild
> cygwin-gcc.
Thanks!
> > - The w32api headers are in their own w32api include directory, but the
> > w32api link libs are in sys-root/usr/lib instead of
> > sys-root/usr/lib/w32api
> > where they belong. I think this should be fixed.
>
> I tried that at first, but it didn't work. The problem is with
> binutils:
>
> $ i686-pc-cygwin-strings /usr/bin/i686-pc-cygwin-ld.bfd | grep w32api
> SEARCH_DIR("/usr/i686-pc-cygwin/lib/w32api");
I don't quite understand how this matches the current installation.
Right now the w32api libs are in sys-root/usr/lib, not in lib. I'm sure
I'm missing something.
Hmm, if you do the same with the mingw version:
$ i686-pc-mingw-strings /usr/bin/i686-pc-mingw-ld.bfd | grep w32api
you get no output at all. The w32api libs are also in the same
directory as the mingw libs, /usr/i686-pc-mingw32/sys-root/mingw/lib.
> So this code isn't sysroot-safe. PTC.
Did you send a patch upstream?
Uh, btw., I helped myself by just adding a symlink:
# cd /usr/i686-pc-cygwin/sys-root/lib
# ln -s . w32api
Maybe that's a valid workaround?
I also found another strange problem. It's practically impossible to
debug a Cygwin DLL built with this gcc/g++. The debug line number
information appears to be screwed up. Like this:
With gcc 4.3.4:
(gdb) break gethostid
Breakpoint 2 at 0x610f6b1a: file [...]/syscalls.cc, line 3718.
(gdb) continue
Continuing.
Breakpoint 2, gethostid ()
at [...]/syscalls.cc:3718
3718 0x00290012);
With gcc 4.5.1:
(gdb) break gethostid
Breakpoint 2 at 0x610ebd9f: file [...]/syscalls.cc, line 94.
(gdb) continue
Continuing.
Breakpoint 2, 0x610ebd9f in gethostid ()
at [...]/syscalls.cc:94
94 for (int i = 0; i < (int) cygheap->fdtab.size; i++)
While the memory address makes sense, the line number does not. If you
now try to step through the function, GDB gets seriosly lost:
(gdb) next
strace::active (this=0x6119c9e0)
at [...]/strace.h:54
54 bool active () const {return _active & 1;}
(gdb) print data
No symbol "data" in current context
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
