325758 - building the mail client using non-system X11

Status: RESOLVED INVALID

(Firefox Build System :: General, enhancement)

Description

[ause]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050921
Build Identifier: checkout from cvs MOZILLA_1_8_BRANCH 

using "--x-includes" and "--x-libraries" gets ignored in some places. especiall applications linking with TK_LIBS only take the X11 libraries supplied by the system.

Reproducible: Always

Steps to Reproduce:
0. have a X11 installation that is noticeable different (here taken from a system using an older version of X11)
1. configure with "--x-includes" and "--x-libraries"
2. build
3.

Actual Results:  
e.g. elf-dynstr-gc links explicitly against gtk2 but doesn't mention any X11 libraries. thus any give -L parameter gets ignored an system X11 is taken.


Expected Results:  
link the X11 lib i pointed to. it's debateable if the sample binary needs gtk at all but the general problem of linking gtx and not X11 remains.

AFAIK, it's a problem not limited to linux but to all builds linking X11

my build configuration is a bit special as i also do not use system libraries nor system includes but a copy of a baseline system i have to stay compatible to. this  is done by additionally specifying the required switche in the according environment variables.

Comment 1

[ause]

Attachment: works around the problem for me. just the first attempt, might need polishing

if there is something wrong or missing , just give me a hint.

Comment 2

[Benjamin Smedberg]

Comment on attachment 210606 [details] [diff] [review]
works around the problem for me. just the first attempt, might need polishing

patches should be to "configure.in" and not "configure"... and I don't understand this patch at all, since it appears to be in a GTK(1) block, which would make setting gtk2 flags a serious mistake.

Comment 3

[ause]

i added configure too as it is committed to cvs (and gabled the change). see configure.in for the correct change.
the point is to link X11 libraries explicit (including -L switch for location) instead of inplicit taking the system X11.

Comment 4

[Benjamin Smedberg]

1) The configure patch is obviously incorrect. The configure.in patch looks like it may be correct. You should always generate configure from configure using autoconf-2.13 (but you don't and shouldn't include it in the patch).

2) NSS shouldn't need X, and if it does we need to figure out why, and the patch should be attached separately, since NSS is a separately managed product and build system.

Comment 5

[ause]

Attachment: stripped configure and NSS stuff

the NSS changes were not really X11 related but rather passing down link/compile flags generally. who do i address to regarding NSS?

Comment 6

[ause]

Comment on attachment 210906 [details] [diff] [review]
stripped configure and NSS stuff

trying again

Comment 7

[cls]

Comment on attachment 210906 [details] [diff] [review]
stripped configure and NSS stuff

Not everything needs to build against X11.  elf-dynstr-gc links against glib(2) which has no X11 dependencies.  And NSS has no X11 dependencies that I know of.

IIRC, there's another bug opened on the TK_LIBS change.  The problem is that gtk2 doesn't list its implicit library dependencies that are determined via shared library dependencies.  Depending upon how the libraries are built (e.g with -rpath), they may pull in the correct libraries regardless.  This change may be necessary anyway for static builds but I'm not completely comfortable with it.

The TK_CFLAGS change is wrong as it affects all platforms.  Besides, it looks like we already universally add XCFLAGS to COMPILE_C{XX}FLAGS.

Comment 8

[ause]

elf-dynstr-gc links MOZ_GTK2_LIBS if MOZ_ENABLE_GTK2. this in turn requires the X libraries to appear. instead of adding to the link line, the X libraries also could be added when overwriting GLIB_LIBS. i'm not sure why this is done at all...

i couldn't find this other issue dealing with TK_LIBS.

you're right, the whole change in autoconf.mk.in is neither good nor required as the needed settings are already done by configure anyway.

Comment 9

[cls]

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/config/Makefile.in&rev=3.124#164

Ugh.  That's what I get for approving patches without being able to test them.  There's unquestionably a better way to remove the gtk1 dependency from gtk2 builds  than pulling in unnecessary dependencies.

Regarding the TK_LIBS change, I was probably thinking of bug 146500 .  I thought we put in a better fix than that though.

Comment 10

[cls]

Attachment: v1

GLIB_CFLAGS/GLIB_LIBS should now always contain the proper values whether we're building against gtk1 or gtk2 so there's no need to override them.

Comment 11

[ause]

Attachment: summing up all comments and still fixing my problem

i can't see a problem in adding X libraries to the gtk libraries as long no one can point me to a gtk version not using X.

Comment 12

[cls]

Comment on attachment 222614 [details] [diff] [review]
summing up all comments and still fixing my problem

You mean http://www.gimp.org/~tml/gimp/win32/ ?

The glib portion of the patch has already been applied to the trunk.

I'm still not compeltely convinced that blindly adding XLIBS to TK_LIBS is what we want to do.  gtk{2}'s pkg-config/.m4  should be smart enough to know when to add the X11 dependencies and when to leave them off.  In fact, they still do appear in the `gtk-config --libs` output.  Can you provide a build log that shows the error that you see without the patch?

Comment 13

[ause]

Attachment: stripped log of the failure

left configure stuff in to give an idea what i'm trying to achive

Comment 14

[cls]

The compile line in that logfile never explicitly lists -L/usr/X11R6/lib nor -lX11.  It looks like there's a shared library dependency upon the system version of libX11.so.6 coming from one of the gtk2/pango libs.  In that case, the build is behaving as expected.  If you want to override the dependency, then you should fix the pkg-config file for your gtk2/pango builds or build them against the non-system version of X11.

Comment 15

[ause]

(In reply to comment #14)
> The compile line in that logfile never explicitly lists -L/usr/X11R6/lib nor
> -lX11.  It looks like there's a shared library dependency upon the system
that's exactly the problem i'm trying to address. when not explicit linking to X11 libraries, the settings done with --x-libraries simply get ignored. from my point of view this is at least inconsitent.

> version of libX11.so.6 coming from one of the gtk2/pango libs.  In that case,
> the build is behaving as expected.  If you want to override the dependency,
silently ignoring configure settings?

> then you should fix the pkg-config file for your gtk2/pango builds or build
> them against the non-system version of X11.
beside xft, none of the prerequisites explicit list th X11 libraries, although using them (and being created with the desired library set). so there is not much to "fix" on this side.

it boils down to the simple question:
why allow to specify custom libraries in configure when they are intentionally ignored in several places? see also 338447

Comment 16

[cls]

> it boils down to the simple question:
> why allow to specify custom libraries in configure when they are intentionally
> ignored in several places? see also 338447

As it was pointed out in bug 338447, the purpose of those options is to configure *mozilla's* explicit use of those specific libraries, not to override every possible use by any dependent libraries.  Keeping track of the dependency trees between various out-of-mozilla-tree libraries has always been the responsibility of the builder.

In the case that you pointed out, mozilla is not explicitly linking against X11 so there's no need for us to add our custom flags.  We expect gtk2's pkg-config output to bring in all of the appropriate dependencies that gtk2 needs to link.  If gtk2 needs the non-system version of X11, then it should list them in the pkg-config output or have a shared library dependency upon the non-system version of X11 instead of the system version of X11.

None of the prerequisites explicitly list the X11 libs because they are using shared library dependencies to load the dependent libs.  This means that your version of gtk2 was built against the system version of X11 or it was improperly built against the non-system verison of X11 (didn't use -rpath or X11 libpath isn't being passed in so that it shows up in the pkg-config output).

The fact that you want to use the non-system version of X11 but your gtk2 libraries are linked against and have shared library dependencies upon the system version of X11 means that your build environment is broken.  You should rebuild your version of gtk2 so that it links against & has shared library dependencies upon your non-system version of X11.