1368363 - "undefined reference to `atk_bridge_adaptor_init'" when trying to build Sm 2.50+ on Linux

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Adrian Kalla [:adriank]]

With Sm 2.50+ when trying to build on Linux, the build ends always with the following error (not matter if building a 32 or 64 bit build):


15:40:37 INFO:root:12:12.62     INPUT("StaticXULComponentsEnd/StaticXULComponentsEnd.o")
15:40:37 
15:40:37 INFO:root:12:12.62 
15:40:37 
15:40:37 INFO:root:12:12.62 ../../accessible/atk/Platform.o: In function `mozilla::a11y::PlatformInit()':
15:40:37 
15:40:37 INFO:root:12:12.62 /home/mozilla/jenkins/workspace/seamonkey-central_linux64/mozilla/accessible/atk/Platform.cpp:190: undefined reference to `atk_bridge_adaptor_init'
15:40:37 
15:40:37 INFO:root:12:12.62 collect2: error: ld returned 1 exit status
15:40:37 
15:40:37 INFO:root:12:12.62 /home/mozilla/jenkins/workspace/seamonkey-central_linux64/mozilla/config/rules.mk:783: recipe for target 'libxul.so' failed
15:40:37 
15:40:37 INFO:root:12:12.62 gmake[4]: *** [libxul.so] Error 1
15:40:37 
15:40:37 INFO:root:12:12.63 /home/mozilla/jenkins/workspace/seamonkey-central_linux64/mozilla/config/recurse.mk:73: recipe for target 'toolkit/library/target' failed
15:40:37 
15:40:37 INFO:root:12:12.63 gmake[3]: *** [toolkit/library/target] Error 2
15:40:37 
15:40:37 INFO:root:12:12.63 /home/mozilla/jenkins/workspace/seamonkey-central_linux64/mozilla/config/recurse.mk:32: recipe for target 'compile' failed
15:40:37 
15:40:37 INFO:root:12:12.63 gmake[2]: *** [compile] Error 2
15:40:37 
15:40:37 INFO:root:12:12.63 /home/mozilla/jenkins/workspace/seamonkey-central_linux64/mozilla/config/rules.mk:519: recipe for target 'default' failed
15:40:37 
15:40:37 INFO:root:12:12.63 gmake[1]: *** [default] Error 2
15:40:37 
15:40:37 INFO:root:12:12.63 client.mk:397: recipe for target 'build' failed
15:40:37 
15:40:37 INFO:root:12:12.63 gmake: *** [build] Error 2


SeaMonkey 2.49.X is the last working version.

First I thought that the ATK version 2.14 from CentOS 7 has become just too old, but now I have tried the build on the latest and up-to-date Fedora 25 with one ATK version 2.22 - and the build results in the same error. The latest stable ATK is 2.24, but I doubt that it would make any difference, though haven't tried it.

I've tried to mess a bit with the code in the failing file - but this did not produce anything working. The last two bugs that made changes on that symbol are already pretty old: bug 1138845 and bug 1110211.


The only working workaround (thx to FRG) is to completely disable accessibility in the mozconfig using "ac_add_options --disable-accessibility" - though I doubt we would like to make an official release using that workaround.

Comment 1

[Frank-Rainer Grahl (:frg)]

Attachment: atk.patch

This is probably caused by the changes in Bug 1138845. I am not that familiar with linking on linux. It seems that atk-bridge is not in the linker path but the linker wants to resolve the weak symbol.

As a workaround you can check for atk-bridge-2.0 in configure. 

You can also set ac_add_options --disable-accessibility but this is a bad idea for distributed builds.

I didn't try a Firefox build but it should fail the same way. 

Fails at least with CentOS 7.3 and some time ago I tried Debian 8.6 with the same result.

With gtk2 no longer supported it might be time to clean up the here and make it a hard requirement.

Mike did the patch. Maybe he can shed some light on this what we do wrong.

Comment 2

[Adrian Kalla [:adriank]]

> I didn't try a Firefox build but it should fail the same way. 

For some reason it does not fail - neither does a Thunderbird build (I've tried them all on the same Fedora 25 machine and using nearly the same mozconfig like for the SeaMonkey build (autogenerated by my build script)).

Comment 3

[Mike Hommey [:glandium]]

Our Gtk+3 requirements haven't changed, so I don't think we can require atk-bridge-2.0. With that being said, there's not enough backlog in comment 0 to tell anything, but there's definitely something wrong going on with the linker. Are you giving extra LDFLAGS?

Comment 4

[Adrian Kalla [:adriank]]

Attachment: fullBuild.log

Comment 5

[Adrian Kalla [:adriank]]

Mike: I've attached the full build log. I do not pass any LDFLAGS manually.

Comment 6

[Mike Hommey [:glandium]]

What's the output for `objdump -t $objdir/accessible/atk/Platform.o | grep atk_bridge`?

Comment 7

[Frank-Rainer Grahl (:frg)]

[root@seabld4711 atk]# objdump -t Platform.o | grep atk_bridge

0000000000000000  w      *UND*  0000000000000000 atk_bridge_adaptor_init

Comment 8

[Mike Hommey [:glandium]]

I don't see an obvious reason why this would fail :( it should just work.

Comment 9

[Frank-Rainer Grahl (:frg)]

If I remove the "C" from extern the linking works but obviously mangles the name in the object. Linking on the official builders works so maybe a problem with specifix gcc or LD versions. But in this case Fx and TB linking should fail too. Strange.

Comment 10

[Frank-Rainer Grahl (:frg)]

Attachment: 1368363-xullink.patch

Upps... 

Now just someone tell me why the official builds are not affected?

Should also fix a Flash problem reported via #seamonkey similar to Bug 1051209 

[Approval Request Comment]
Regression caused by (bug #): Bug 1318735
User impact if declined: No 2.51+
Testing completed (on m-c, etc.): c-c CentOS 7.3 gcc 5.3.1
Risk to taking this patch (and alternatives if risky): none
String changes made by this patch: --

Comment 11

[Ian Neal]

Comment on attachment 8874128 [details] [diff] [review]
1368363-xullink.patch

># HG changeset patch
># User Frank-Rainer Grahl <[e-mail]>
># Parent  363757bf9224afbbf0a14d3b4da4ae018f4590cb
>Bug 1368363 - Do not link gtk libs into xul library.
>
>diff --git a/suite/build/moz.build b/suite/build/moz.build
>--- a/suite/build/moz.build
>+++ b/suite/build/moz.build
>@@ -21,10 +21,8 @@ LOCAL_INCLUDES += [
>     '/suite/shell/src',
> ]
> 
> if CONFIG['OS_ARCH'] == 'WINNT':
>     OS_LIBS += [
>         'ole32',
>         'shell32',
>     ]
>-
>-OS_LIBS += CONFIG['TK_LIBS']

Do we still need the ole32 and shell32 bits?

r/a=me with that answered

Comment 12

[Frank-Rainer Grahl (:frg)]

Attachment: 1368363-xullink-V2.patch

> Do we still need the ole32 and shell32 bits?

No. See also Bug 1302855 where this was done for the browsercomps library.

Patch updated. r+ and approval‑comm‑beta from IanN retained.

IanN could you set approval-comm-beta to + again. I don't have the rights and it would look bad when checked in.

Comment 13

[Frank-Rainer Grahl (:frg)]

https://hg.mozilla.org/comm-central/rev/579eb9c5ef678d876a9386088753daecf3a4e02d

Comment 14

[Ian Neal]

Comment on attachment 8874134 [details] [diff] [review]
1368363-xullink-V2.patch

a=me

Comment 15

[Frank-Rainer Grahl (:frg)]

https://hg.mozilla.org/releases/comm-beta/rev/45a6f07f01e0fab8ae47a37db87bf975900e6c16