"Christian T. Steigies" wrote: > > On Mon, Jan 08, 2001 at 07:01:00PM +0100, Michel Dänzer wrote: > > > With 4.0.2 installed: > > > > ~> strings /usr/X11R6/lib/modules/fonts/libbitmap.a|grep memcpy > > xf86memcpy > > > > > > memcpy is #defined to xf86memcpy in > > xc/programs/Xserver/hw/xfree86/os-support/xf86_libc.h > > > > So something goes very wrong with your build. > Tell me... and _that_ part _was_ working in a previous build. And I did not > change much on my build system since then, I only installed (and built) > glibc2.2 and gcc-2.95.3 ;-)
[...] > And for all I can say, the source in the bitmap directory did not change > since quite some time, so I wonder why the binaries do not work anymore? I don't think the problem are the bitmap sources, bitmap is the first module loaded so I imagine the other modules alse reference wrong symbols. I really suspect there's something wrong with your glibc headers or the compiler. > When I perform you strings command on a previous version, I get: > strings libbitmap.a | grep memcpy > memcpy > xf86memcpy > memcpy > > Not sure if loading libbitmap was working here, I just unpackage the dep. > Will check that again at home. But you see I get memcpy twice plus > xf86memcpy once. Is that ok? Better yet: check with objdump -t . It should only reveal xf86memcpy, not plain memcpy. The same for all standard libc functions. I guess you'll have to track down what happens with a source file whose compiled object contains a wrong symbol. 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
