This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fedora Cygwin RPM repository


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]