1

When using the "lazy linking" link option "-lazy-lz" referenced in this question to delay the loading of a dependent dynamic library, the linker that's part of Xcode 7.2.1 (Apple LLVM version 7.0.2 (clang-700.1.81)), generates this error:

ld: illegal data reference to __ZN9WBRefSpecD1Ev in lazy loaded dylib

...where the mangled C++ symbol refers to the class destructor in my single-class dylib: _WBRefSpec::~WBRefSpec()

I can't find a direct reference anywhere to indicate what this error could possibly mean -- or what could cause it.

In the .cpp file, the destructor is defined:

EXPORT WBRefSpec::~WBRefSpec(void)
{
    ClearEntireRefSpec();  // commenting out this call doesn't affect error message!
}

...where EXPORT is the usual:

#define EXPORT __attribute__((visibility("default")))

...and of course, defined in the header file as a public member of the class:

~WBRefSpec(void);

Anyone ever seen this or have a clue what causes this error?

EDIT / ANSWER:

The answer to the illegal data reference was that there WAS a .cpp file with a class member function defined that declared "static WBRefSpec foo;" Removed that, and bingo, no link error.

(removed link details, since they were not relevant to the issue)

Community
  • 1
  • 1
SMGreenfield
  • 1,680
  • 19
  • 35
  • post how you're building/linking your full program, please – xaxxon May 13 '16 at 03:30
  • The dylib probably needs to bind a non-lazy pointer with the other in order to work. – l'L'l May 13 '16 at 03:40
  • @xaxxon -- Link settings posted (some paths "sanitized"). Should I have formatted it to wrap for better readability? – SMGreenfield May 13 '16 at 04:02
  • 1
    @l'L'l -- Well, otool says the dylib depends on /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon, /usr/lib/libstdc++.6.dylib, and /usr/lib/libSystem.B.dylib. Is that what you mean? Pretty hard to avoid those, particularly libstdc++. – SMGreenfield May 13 '16 at 04:08
  • 1
    I'm meaning more like `extern void WBRefSpec(void);` https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachOTopics/1-Articles/indirect_addressing.html – l'L'l May 13 '16 at 04:37
  • @l'L'l -- Would a constructor ever be declared returning void? I've searched my entire project and didn't see anything like that. Should my header have EXPORT in front of every member? – SMGreenfield May 13 '16 at 04:45
  • @SMGreenfield: In `C` it's possible (my mind must have drifted). The `extern` really is the only thing I was trying to emphasize, for an example of the code that determines why you get the error maybe take a look at this [this](https://gist.github.com/anonymous/695d2c5f59b4f01c7dfc3bf9fc582da3#file-outputfile-cpp-L3041-L3050), the error message should seem familiar. – l'L'l May 13 '16 at 06:06
  • 1
    @l'L'l -- Final comment: The answer to the illegal data reference was that there WAS a .cpp file with a class member function that declared "static WBRefSpec foo;" Removed that, and bingo, no link error. – SMGreenfield May 14 '16 at 00:09

1 Answers1

0

The answer to the illegal data reference was that there WAS a .cpp file with a class member function defined that declared "static WBRefSpec foo;"

WBRefSpec& XMLErrorLogFile::GetLogFileInAppFolder()
{
    static WBRefSpec logFileInAppFolder;
    return logFileInAppFolder;
}

As a test, I removed static, and bingo, no link error.

But NOTE: just editing out "static" in this case would a Very Bad Idea and create another Very Serious Problem: returning a reference to an object allocated on the stack!

I think if I make a class data member that's a static WBRefSpec*, and just initialize it in my function (but only once) then the issue will also go away.

The irony is that I choose that pattern based on an excellent SO answer to someone else's unrelated posting.

Community
  • 1
  • 1
SMGreenfield
  • 1,680
  • 19
  • 35