1503350 - mozconfig option "--disable-negotiateauth" causes link problem with functions in nsIAuthModule and nsHttpNegotiateAuth after bug 1502774

Status: ASSIGNED

(Core :: Networking, defect, P5)

Description

[:aceman]

Since today I have problem with the build on Linux which fails at linking libxul.so:
/usr/bin/ld.gold: error: mozilla/obj-x86_64-pc-linux-gnu/toolkit/library/../../netwerk/protocol/http/Unified_cpp_protocol_http2.o: requires dynamic R_X86_64_PC32 reloc against '_ZTV19nsHttpNegotiateAuth' which may overflow at runtime; recompile with -fPIC
/usr/bin/ld.gold: error: read-only segment has dynamic relocations

comm/mailnews/addrbook/src/nsAbLDAPListenerBase.cpp:267: error: undefined reference to 'nsIAuthModule::CreateInstance(char const*)'
mozilla/obj-x86_64-pc-linux-gnu/toolkit/library/../../comm/mailnews/addrbook/src/nsAbLDAPListenerBase.o(.debug_addr+0xf18): error: undefined reference to 'nsIAuthModule::CreateInstance(char const*)'
mozilla/comm/mailnews/base/util/nsMsgProtocol.cpp:956: error: undefined reference to 'nsIAuthModule::CreateInstance(char const*)'
mozilla/comm/mailnews/base/util/nsMsgProtocol.cpp:865: error: undefined reference to 'nsIAuthModule::CreateInstance(char const*)'

mozilla/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp:1104: error: undefined reference to 'nsHttpNegotiateAuth::GetOrCreate()'
mozilla/extensions/auth/nsHttpNegotiateAuth.h:18: error: undefined reference to 'vtable for nsHttpNegotiateAuth'
/usr/bin/ld.gold: the vtable symbol may be undefined because the class is missing its key function
mozilla/netwerk/build/nsNetModule.cpp:624: error: undefined reference to 'nsAuthGSSAPI::Shutdown()'
collect2: error: ld returned 1 exit status
gmake[4]: *** [mozilla/config/rules.mk:712: libxul.so] Error 1

I'm using gold linker (but the same error shows when using ld (bfd) and GCC 8.2 (which worked till today).

Possibly affected by bug 1502774 which touches the files with nsHttpNegotiateAuth and nsIAuthModule .

Comment 1

[:aceman]

May be related to bug 1503053, however that one already failed at compilation (and can also be seen on https://treeherder.mozilla.org/#/jobs?repo=try-comm-central)
while this one is only at link time.

Comment 2

[Jorg K (CEST = GMT+2)]

Builds OK on M-C and C-C tip after two backouts.

Comment 3

[:aceman]

It's back, bug 1502774 has re-landed.

Comment 4

[Jorg K (CEST = GMT+2)]

I can assure you that bug 1503053 has also re-landed and everything compiles.

Comment 5

[:aceman]

I updated today so bug 1503053 should be in, if relanded. And only now the error has appeared.
Also, there is no compilation problem, but a linking problem.
Notice that exactly the calls to nsIAuthModule::CreateInstance() that were added in bug 1503053 are failing here (and also some others in mozilla-central).

Comment 6

[:ehsan akhgari]

Hmm, aceman, is the linking issue caused because the code in comm/mailnews/addrbook is being linked outside of libxul?

If yes, does the error go away if you wrap this C++ block <https://searchfox.org/mozilla-central/rev/efc0d9172cb6a5849c6c4fc0f19d7fd5a2da9643/netwerk/base/nsIAuthModule.idl#137> in an #ifndef MOZILLA_INTERNAL_API / #endif block?

Comment 7

[Jorg K (CEST = GMT+2)]

I think it's due to Aceman's mozconfig. To save 30 sec compile time he's not building part of the system only to spend hours later debugging it ;-( - Everyone else *can* compile and compiles in automation work as well.

Comment 8

[:aceman]

Right, but if I only use the exposed mozconfig options, they are supposed to work.

So I found out this particular link problem is caused by this option:
ac_add_options --disable-negotiateauth

Is it an expected outcome of that option to fail the link?
Possibly some features will be compiled out, but should otherwise build. So at least the m-c code seems to be missing some #ifdefs. We can then adapt c-c.

Comment 9

[Jorg K (CEST = GMT+2)]

Oops, this was a Core::Networking bug which I over-zealously closed. My apologies!

Comment 10

[:ehsan akhgari]

(In reply to :aceman from comment #8)
> Is it an expected outcome of that option to fail the link?
> Possibly some features will be compiled out, but should otherwise build. So
> at least the m-c code seems to be missing some #ifdefs. We can then adapt
> c-c.

It is not _expected_, of course.  But usually build configurations that aren't the default on our CI infrastructure break from time to time and it's up to people who care about those configurations to fix them.  In this case, there isn't a preprocessor macro activated when --enable-negotiateauth is specified so this isn't a simple fix of just wrapping the block I mentioned in comment 6 in an #ifdef and requires a bit of build system work to add such a preprocessor macro first.  Unfortunately I don't have time to spend on it, but it should be simple enough if you care to write a patch yourself (look for places where we AC_DEFINE preprocessor macros based on similar configure arguments in the configure script for examples.)

Comment 11

[Horst]

I have the same problem with firefox 84.0.2 (building from source).

It seems that aside from the missing macro, /extensions/auth is always included in a couple of places:

https://searchfox.org/mozilla-central/source/netwerk/build/moz.build#24
https://searchfox.org/mozilla-central/source/netwerk/protocol/http/moz.build#176

Note: nsIAuthModule::CreateInstance is also used by NTLM: https://searchfox.org/mozilla-central/source/netwerk/protocol/http/nsHttpNTLMAuth.cpp#191,201,227
the auth module is returning the appropriate NTLM module: https://searchfox.org/mozilla-central/source/extensions/auth/nsIAuthModule.cpp#31,34,47
It looks like sys-ntlm/nsAuthSSPI is part of extensions/auth while the internal implementation is using https://searchfox.org/mozilla-central/source/security/manager/ssl/nsNTLMAuthModule.h#12 (even though it's flagged as less secure: https://searchfox.org/mozilla-central/source/netwerk/protocol/http/nsHttpNTLMAuth.cpp#224).

I've added a patch based on this (with NTLM disabled) but I'd like some input on what to do with NTLM.

Comment 12

[Horst]

Attachment: 0001-Fix-compile-error-with-disable-negotiateauth-and-don.patch

Comment 13

[Jens Stutte [:jstutte]]

Kershaw, can you help here or do you know who can?

Comment 14

[Kershaw Chang [:kershaw]]

(In reply to Horst from comment #11)

I have the same problem with firefox 84.0.2 (building from source).

It seems that aside from the missing macro, /extensions/auth is always included in a couple of places:

https://searchfox.org/mozilla-central/source/netwerk/build/moz.build#24
https://searchfox.org/mozilla-central/source/netwerk/protocol/http/moz.build#176

Note: nsIAuthModule::CreateInstance is also used by NTLM: https://searchfox.org/mozilla-central/source/netwerk/protocol/http/nsHttpNTLMAuth.cpp#191,201,227
the auth module is returning the appropriate NTLM module: https://searchfox.org/mozilla-central/source/extensions/auth/nsIAuthModule.cpp#31,34,47
It looks like sys-ntlm/nsAuthSSPI is part of extensions/auth while the internal implementation is using https://searchfox.org/mozilla-central/source/security/manager/ssl/nsNTLMAuthModule.h#12 (even though it's flagged as less secure: https://searchfox.org/mozilla-central/source/netwerk/protocol/http/nsHttpNTLMAuth.cpp#224).

I've added a patch based on this (with NTLM disabled) but I'd like some input on what to do with NTLM.

I guess we can only disable NTLM if --disable-negotiateauth is defined. Returning null in nsHttpNTLMAuth::GetOrCreate() would be better.

Comment 15

[Horst]

Attachment: Bug 1503350 - fix compile error when using --disable-negotiateauth