190783 - Failure to link mozilla-bin

Status: VERIFIED WONTFIX

(SeaMonkey :: Build Config, defect)

Description

[Colin Blake]

The build is broken on OpenVMS. When linking mozilla-bin, two symbols are not found:

%LINK-W-NUDFSYMS, 2 undefined symbols:
%LINK-I-UDFSYM,         nsStringAllocator<char > &StringAllocator_char()
%LINK-I-UDFSYM,         nsStringAllocator<unsigned short >
&StringAllocator_wchar_t()

These symbols are in libstring_s.a and that library is referecned at link time.
But the symbols aren't getting resolved. Why? On OpenVMS the order in which
files are referenced is important; a library must be referenced AFTER any
references to that library, otherwise it won't get loaded. That's what's
happening here. The reference to the two symbols is (I think) coming from code
in template instantiations, and that appears to be getting loaded last by the
linker on OpenVMS. So at the time when libstring_s.a is encountered by the
linker, those two symbols have not yet been referenced and so the module is not
loaded.

The fix (not sure if its the right fix) is to force these static libraries to be
loaded. For now I've jsut forced libstring and that fixes my link problem, but
maybe all four static libs should be forced?

This has happened as a result of the GRE build changes.

Comment 1

[Colin Blake]

Attachment: Force load of libstring_s

Comment 2

[Colin Blake]

Setting ? for blocking1.3b flag, since this IS a blocker for OpenVMS.

Comment 3

[Doug Turner (:dougt)]

Comment on attachment 112744 [details] [diff] [review]
Force load of libstring_s

if seawood say okay...

Comment 4

[hacker formerly known as [e-mail]]

Comment on attachment 112744 [details] [diff] [review]
Force load of libstring_s

I'm not convinced that this is the right fix. Usually, the fix for unresolved
symbols is reordering the libraries on the link line.  If the libraries have
circular dependencies, then we do the force load of every symbol to treat the
libraries as a group.  Are you certain that the template instantiations are
being added last by the linker and that it's not a problem of embedstring_s
having unresolved symbols due to  using a header which instantiates those
templates, in which case, we could just link against embedstring_s first?

Comment 5

[Colin Blake]

Putting embedstring_s first, and/or libstring_s last, doesn't cure the problem.
I'd already tried that :-(

Comment 6

[hacker formerly known as [e-mail]]

Comment on attachment 112744 [details] [diff] [review]
Force load of libstring_s

Hrm. Ok.  I guess we can do this for now and look for a better fix in the
future.

Comment 7

[Colin Blake]

Comment on attachment 112744 [details] [diff] [review]
Force load of libstring_s

I found a way to force my linker to include all template instantiations. By
specifying these flags in my LDFLAGS I no longer need this change.

Comment 8

[Colin Blake]

Comment on attachment 112744 [details] [diff] [review]
Force load of libstring_s

Clearing "approval1.3b" request flag.

Comment 9

[Colin Blake]

Clearing "blocking1.3b" ? flag and closing.

Comment 10

[Tracy Walker [:tracy]]

verifying per comments