144182 - Static linking and xlib do not mix

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P2)

Description

[Michael Sinz]

If you set --enable-toolkit-xlib Mozilla will not link.

It fails because the libgfx_xlib.a file is placed into components_inactive but
the link really wants them in components.  Thus the make fails not knowing how
to build the components/libgfx_xlib.a file.  (Which would have resulted in a
link failure if the dependancy was not there)

This happens because the default toolkit is GTK for the platform.  The
configure.in code checks this to determin the location.  By setting the
--enable-default-toolkit=xlib the build/link then fails with the following:


nsStaticComponents.o: In function `nsWidgetXLibModule_NSGetmodule':
nsStaticComponents.o(.text.nsWidgetXLibModule_NSGetmodule+0x9): undefined
reference to `nsWidgetXLibModule_gModuleInfo'
../../dist/lib/libxlibxtbin.a(xlibxtbin.o): In function `xtbin::xtbin_init(void)':
xlibxtbin.o(.xtbin::text.xtbin_init(void)+0x35): undefined reference to
`XtDisplayToApplicationContext'

(and related errors as they continue down the screen...)

Both times this was from a clean build.  (make -f client.mk clean)

We were looking into using xlib since the remaining benefits of GTK are not
actually in play in our environment.  (Other than needing a static linking for
performance and resource issues)

Note that I have the following:

ac_add_options --enable-crypto
ac_add_options --disable-debug
ac_add_options --enable-optimize="-O2 -march=i686"
ac_add_options --disable-ldap
ac_add_options --disable-bidi
ac_add_options --disable-tests
ac_add_options --enable-reorder
ac_add_options --enable-toolkit-xlib
ac_add_options --enable-default-toolkit=xlib
ac_add_options --disable-shared
ac_add_options --enable-static

Comment 1

[timeless]

.

Comment 2

[hacker formerly known as [e-mail]]

Attachment: Fix module name issue & link against XT_LIBS for xlib static builds

T_LIBS will be defined when the patch for bug 126163 lands.  This still
doesn't clear up the secondary toolkit issue.  We should probably exit
configure early if mutiple toolkits are specified for a static build.

Comment 3

[Brian Ryner (not reading)]

Comment on attachment 83445 [details] [diff] [review]
Fix module name issue & link against XT_LIBS for xlib static builds

r=bryner

Comment 4

[hacker formerly known as [e-mail]]

Patch has been checked in on the trunk.

Comment 5

[hacker formerly known as [e-mail]]

.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 83445 [details] [diff] [review]
Fix module name issue & link against XT_LIBS for xlib static builds

Please land this on the 1.0.1 branch.  Once there, replace the
"mozilla1.0.1+" keyword with the "fixed1.0.1" keyword.