Philip Blundell wrote: > > >memcpy is #defined to xf86memcpy in > >xc/programs/Xserver/hw/xfree86/os-support/xf86_libc.h > > > >So something goes very wrong with your build. > > GCC can generate calls to memcpy on its own for structure copies and the > like. That symbol always needs to be available, you can't just #define it > away. That's a problem because XFree86 has its own module loader for portability of the modules. Isn't there a way to force the compiler to include such functions statically or something? Michel -- Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and the DRI project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
- Re: XFree86 4.0.2 status Christian T . Steigies
- Re: XFree86 4.0.2 status Branden Robinson
- Re: XFree86 4.0.2 status Daniel Jacobowitz
- Re: XFree86 4.0.2 status Branden Robinson
- Re: XFree86 4.0.2 status djw
- Re: XFree86 4.0.2 status Paul Slootman
- Re: XFree86 4.0.2 status Michel Dänzer
- Re: XFree86 4.0.2 status Christian T. Steigies
- Re: XFree86 4.0.2 status Michel Dänzer
- Re: XFree86 4.0.2 status Philip Blundell
- Re: XFree86 4.0.2 status Michel Dänzer
- Re: XFree86 4.0.2 status Philip Blundell
- Re: XFree86 4.0.2 status Tor Slettnes
- Re: XFree86 4.0.2 status Michel Dänzer
- Re: XFree86 4.0.2 status Tor Slettnes
- Re: XFree86 4.0.2 status Christian T. Steigies
- Re: XFree86 4.0.2 status Christian T. Steigies
- Re: XFree86 4.0.2 status Michel Dänzer
- Re: XFree86 4.0.2 status Christian T. Steigies
- Re: XFree86 4.0.2 status Michel Dänzer
- Re: XFree86 4.0.2 status Christian T. Steigies