Bug 11543 – multiple definition of std.regex with shared library
Status
RESOLVED
Resolution
FIXED
Severity
critical
Priority
P3
Component
dmd
Product
D
Version
D2
Platform
All
OS
Linux
Creation time
2013-11-18T12:07:00Z
Last change time
2014-06-06T16:53:17Z
Keywords
dll, industry, pull
Assigned to
code
Creator
g.sayol
Comments
Comment #0 by g.sayol — 2013-11-18T12:07:11Z
test.d
---
import std.net.curl;
void main()
{
char[] a = get("http://dlang.org/index.html");
}
---
If liking against phobos shared library, dmd v2.064.2 fails:
$ dmd -L-lcurl -defaultlib=libphobos2.so -run test.d
Fatal Error while loading '/usr/lib/x86_64-linux-gnu/libphobos2.so.0.64':
The module 'std.regex' is already defined in 'test'.
--- killed by signal 11
No problem if static linking.
No problem with dmd v2.063.2 (static and shared linking).
Comment #1 by alexander.breckel — 2013-11-20T12:12:55Z
I get a similar error with:
test.d
---
import std.range;
void main()
{
zip([0]);
}
---
$ dmd -defaultlib=libphobos2.so -run test.d
Fatal Error while loading '/usr/lib/libphobos2.so.0.64':
The module 'std.range' is already defined in './test'.
Segmentation fault (core dumped)
Comment #2 by alexander.breckel — 2013-11-20T14:44:50Z
Here is another minimal test case:
main.d
---
import blubb;
void main() {
f!int();
}
---
blubb.d
---
void f(T)() {
final switch(false) {
case true:
}
}
---
$ dmd -defaultlib= -shared -fPIC -oflibblubb.so blubb.d
$ dmd -defaultlib=libphobos2.so -ofmain main.d -L-lblubb -L-L.
$ LD_LIBRARY_PATH=. ./main
Fatal Error while loading './libblubb.so':
The module 'blubb' is already defined in './main'.
I couldn't reduce the test case any further. Using a non-final switch or an if-statement does not trigger the error.
Maybe the error message correlates with this:
$ nm main
...
0000000000600f50 B _D5blubb12__ModuleInfoZ
...
whereas an error-free version of main contains no blubb.__ModuleInfo
Comment #3 by code — 2013-12-24T11:19:55Z
This happens because of copy relocations, i.e. linker generates a copy of the ModuleInfo symbol in the executable's .bss section.
This causes a false alarm in the druntime code that checks for duplicated ModuleInfos.
There are two/three ways to fix this.
- Make ModuleInfos immutable, which is something we should do anyhow.
- Avoid references to foreign ModuleInfos, a bit more complex but necessary
for https://github.com/D-Programming-Language/dmd/pull/2561.
- Adapt the druntime code to detect this false error. Somewhat dirty hack.
Comment #4 by bugzilla — 2014-01-12T13:12:35Z
Is this really a regression? I don't think we had shared library support before 2.064.
Comment #5 by code — 2014-02-01T12:43:00Z
As an intermediate workaround, it seems that this issue doesn't occur when building optimized binaries (-release -O -inline).
Comment #6 by code — 2014-02-01T16:12:28Z
Only -release is needed.
I think that is because non-release build reference other ModuleInfos for assert and bounds-checking, (see https://github.com/D-Programming-Language/dmd/pull/2561).
Anyhow we should still make ModuleInfo read-only.
Comment #7 by john.loughran.colvin — 2014-05-09T11:51:25Z
I'm still having this problem. Has there been any progress?