fix for Issue 11543 - multiple definition of std.regex with shared library #791
Conversation
…brary - Detect copy relocated ModuleInfos when checking for conflicting module definitions.
| } | ||
| // Module is in .bss of the exe because it was copy relocated | ||
| } | ||
| else if (!findSegmentForAddr(info, addr)) |
There was a problem hiding this comment.
This pull contains another change which is required for dlang/dmd#3551, it will no longer assume that all ModuleInfos are contained in the same segment.
|
Anyone wants to review this? @andralex |
|
👍 |
|
Auto-merge toggled on |
|
Thanks, waiting for the spurious OSX failure to be retested. |
fix for Issue 11543 - multiple definition of std.regex with shared library
|
Mail discussion with @klickverbot:
Those globally visible symbols are defined by the linker script. __bss_start = .; So they are defined in any DSO, but the ones in the executable will override the ones in a shared library. |
|
@MartinNowak: Okay, a quick test seems to indeed confirm that they are overridden with the bracketing symbols from the executable. So back to the beginning for me in trying to figure out why the check fails on LDC (without the module infos actually being duplicated), but it should be fine for DMD. Apparently I had misread the section maps, need to recheck… |
|
@MartinNowak: Okay, and now I can't even reproduce the issue at all. Well, speaks for your implementation, I guess. ;) |
Glad to hear this :). |
fix for Issue 11543 - multiple definition of std.regex with shared library The copy relocations for the ModuleInfo symbols generated by the linker when building the main executable without PIC enabled were throwing the module collision detection off.
conflicting module definitions.
Issue 11543