Bug 772817
Summary: | 4.7 regression: unable to build mame, linking failure: undefined reference to foo | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Julian Sikorski <belegdol> | ||||
Component: | gcc | Assignee: | Jakub Jelinek <jakub> | ||||
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | rawhide | CC: | jakub, kevin, pmachata | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2012-01-10 15:21:43 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Julian Sikorski
2012-01-10 02:14:50 UTC
g++ doesn't default to -std=c++11 yet, it defaults to -std=gnu++98. And your reproducer is bogus, because malloc_file_line isn't defined anywhere. You need a definition for that somewhere, and as it isn't prototyped with extern "C", it needs to be a C++ symbol too. So, please look first which source file is supposed to provide that symbol, which does that when you compile with 4.6 and what changed that it doesn't provide it anymore with gcc 4.7. I think this function is defined in src/emu/emualloc.h, but then my coding skills are negligible so I might be talking nonsense: http://mamedev.org/source/src/emu/emualloc.h.html As for the reproducer, Petr, could you please comment on that? No, the function is not defined in emualloc.h, it's only declared as a prototype, i.e. a forward declaration. There's no actual definition there. I see. I am not sure where to look though, since the only references to malloc_file_line and free_file_line google returns come back to mame. Created attachment 551819 [details] differences between 4.6.2 and 4.7.0 versions of <new> The function is defined in http://mamedev.org/source/src/emu/emualloc.c.html I am attaching the differences in the header file. I tried fiddling with extern "C", but so far without success. So the difference is probably the externally_visible attribute which got added in the prototype for operator new(size_t), which keeps the function from being optimized away even though it is marked always_inline and not used. So I think the code already didn't work as intended with g++ 4.6.2, the replaced new function wasn't being used at all, which is why the unresolved reference went unnoticed. Would the fix be to rename it? I prompted opening of a bug report because there doesn't seem to be any reason to emit body of operator new. It's declared as inline and only called from inline function whose body is also not emitted. That's a change from GCC 4.6. Apparently the flags defined in <new> at operator new (__externally_visible__?) take precedence. If it's not a bug, then so much the better. (Adding in libemu as a dependency is not an option, that leads to circular dependencies. Julian, just use that #define hack that I posted.) Julian, about that c++11 thing, it turns out that they are all _warnings_, but -Werror turns them into errors. I missed that detail before. I think the sane way out is to build with make NOWERROR=1, otherwise you'd have to plow through it all and either turn off individual warnings or fix actual offending code. Kevin, I think it's just included coincidentally. They need some declarations, but the chain of includes also brings in the operator new. They never actually use any of that code (the file is in fact a .c file, just massaged through the c++ compiler) in the module itself. It was okay up until now, but it breaks now that GCC emits the (actually unused) function body. NOWERROR=1 is actually used by the RPM spec, you must have tried with plain make. I can also confirm that your workaround has fixed the linking issue. I'll forward these findings to upstream. (In reply to comment #8) > I prompted opening of a bug report because there doesn't seem to be any reason > to emit body of operator new. It's declared as inline and only called from > inline function whose body is also not emitted. That's a change from GCC 4.6. > Apparently the flags defined in <new> at operator new (__externally_visible__?) > take precedence. If it's not a bug, then so much the better. I don't think it is a bug. operator new is quite special and the externally_visible attribute on it is certainly desirable, the C++ standard requires that you can override the operator new. See PR50594. As for -Werror, every GCC major version adds or removes some warnings, if something is built with -Werror, you need to be prepared to adjust your code, either to fix up real code bugs or workaround false positive warnings, or disable individual warnings from erroring out (-Wno-error=warningname). (In reply to comment #10) > NOWERROR=1 is actually used by the RPM spec, you must have tried with plain > make. Yes, that's true. |