Bug 3327 – OPTLINK and the librarian fail to see a symbol in a library

Status
REOPENED
Severity
normal
Priority
P3
Component
tools
Product
D
Version
D1 (retired)
Platform
x86
OS
Windows
Creation time
2009-09-17T18:45:37Z
Last change time
2022-12-17T10:45:44Z
Keywords
Optlink
Assigned to
No Owner
Creator
Tomasz Stachowiak

Attachments

IDFilenameSummaryContent-TypeSize
452strangeLib.7zThe Lib That Failsapplication/octet-stream423518

Comments

Comment #0 by h3r3tic — 2009-09-17T18:45:37Z
Excerpt from the d.D newsgroup (Incremental compilation with DMD): `Somewhere in the process a library is created that confuses OPTLINK as well as "lib -l". There's one symbol in it that neither of these are unable to see and it results in an undefined reference when linking. The symbol is clearly there when using a lib dumping tool from DDL or "libunres -d -c". (...) it can be found via a regex "D2xf3omg4core.*ctFromRealVee0P0Z".` My guess: there's a mismatch between the lib dictionary and its actual contents. I can provide reproduction steps if necessary but they will be rather involved. Maybe the intermediate .lib files and operations using the librarian would be useful?
Comment #1 by h3r3tic — 2009-09-17T18:47:18Z
Created attachment 452 The Lib That Fails Bugzilla failed to attach it directly to the post
Comment #2 by pro.mathias.lang — 2021-01-09T06:50:17Z
I'm going to close this as stale. While there's no guarantee the bug has been fixed, this bug is over a decade old and hasn't been addressed. Moreover it's for a platform that is seeing little to now use nowadays (x86). Finally, using lld-link will get you much better results nowadays.
Comment #3 by bugzilla — 2021-01-25T01:17:14Z
Reopened because it's still an unresolved bug.
Comment #4 by pro.mathias.lang — 2021-01-25T01:28:35Z
@Walter: Then it should be transferred to https://github.com/DigitalMars/optlink