Julian Sikorski <beleg...@gmail.com> writes:
> I was trying to build mame (an rpmfusion package) with gcc-4.7. I have
> managed to get it to build, but it fails at the linking stage:
>
> obj/sdl/libocore.a(sdlsocket.o): In function `operator new(unsigned long)':
> /builddir/build/BUILD/mame-0.144u5/src/emu/emualloc.h:114: undefined
> reference to `malloc_file_line(unsigned long, char const*, int)'
> obj/sdl/libocore.a(sdlsocket.o): In function `operator delete(void*)':
> /builddir/build/BUILD/mame-0.144u5/src/emu/emualloc.h:131: undefined
> reference to `free_file_line(void*, char const*, int)'
> collect2: error: ld returned 1 exit status
The problem boils down to the following reproducer:
#include <new>
#include <cstddef>
void *malloc_file_line(size_t size, const char *file, int line);
__attribute__((always_inline)) inline void *
operator new(std::size_t size) {
return malloc_file_line(size, __null, 0);
}
struct item {
void add() { new item; }
};
int main(int argc, char *argv[]) {
return 0;
}
# g++ ble.cc
/tmp/ccwc7vSd.o: In function `operator new(unsigned long)':
ble.cc:(.text._Znwm[_Znwm]+0x1e): undefined reference to
`malloc_file_line(unsigned long, char const*, int)'
If #include <new> is removed, the problem goes away. I suspect there
might be another declarations of new operator in that header file, and
the two are not going well together. Would you be so kind as to open a
bug against gcc? It looks like something that responsible parties
should take a look at, what with all the "inline" and "always_inline"
stuff that GCC seems to be ignoring.
To work around your immediate problem, I think you might #define
NO_MEM_TRACKING before including emu.h, like this:
diff -up mame-0.144u5/src/osd/sdl/sdlsocket.c\~
mame-0.144u5/src/osd/sdl/sdlsocket.c
--- mame-0.144u5/src/osd/sdl/sdlsocket.c~ 2012-01-10 00:34:48.000000000
+0100
+++ mame-0.144u5/src/osd/sdl/sdlsocket.c 2012-01-10 02:13:51.293943347
+0100
@@ -23,6 +23,7 @@
#endif
#include <errno.h>
+#define NO_MEM_TRACKING
#include "emu.h"
#include "sdlfile.h"
It then proceeds for a bit before hitting a C++11 correctness problem.
You might consider smuggling in -std=c++98 and alarm upstream, it seems
GCC 4.7 defaults to C++11 and the code is not ready for this.
Thanks,
PM
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
