Closed
Bug 648721
Opened 12 years ago
Closed 12 years ago
Fix linking of xpcshell and plugin-container (X libs path missing)
Categories
(Firefox Build System :: General, defect)
Firefox Build System
General
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla6
People
(Reporter: gaston, Assigned: gaston)
References
Details
Attachments
(2 files, 2 obsolete files)
580 bytes,
patch
|
glandium
:
review+
|
Details | Diff | Splinter Review |
1.02 KB,
patch
|
glandium
:
review-
|
Details | Diff | Splinter Review |
currently, when linking xpcshell | plugin-container, it fails with the following error : c++ -o xpcshell -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor - Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -O2 -pipe -fno-strict-aliasing -fshort-wchar -pthread -pipe -DND EBUG -DTRIMMED xpcshell.o -pthread -Wl,-rpath,'/usr/local/lib/firefox-4.0' -Wl,-rpath-link,/usr/obj/mozilla-firefox-4.0/mozilla-2.0/di st/bin -Wl,-rpath-link,/usr/local/lib -L/usr/obj/mozilla-firefox-4.0/mozilla-2.0/dist/bin -L../../../../dist/bin -L../../../../dist/lib ../ ../../../dist/lib/libxpcomglue_s.a -L/usr/obj/mozilla-firefox-4.0/mozilla-2.0/dist/bin -lxpcom -lmozalloc -lxul -L/usr/obj/mozilla-firefox- 4.0/mozilla-2.0/dist/bin -lxpcom -lmozalloc -lxul -L/usr/local/lib -lplds4 -lplc4 -lnspr4 -pthread -lc /usr/bin/ld: warning: libSM.so.8.0, needed by /usr/X11R6/lib/libXt.so.10.0, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libICE.so.9.0, needed by /usr/X11R6/lib/libXt.so.10.0, not found (try using -rpath or -rpath-link) /usr/X11R6/lib/libXt.so.10.0: undefined reference to `SmcSaveYourselfDone' /usr/X11R6/lib/libXt.so.10.0: undefined reference to `IceConnectionNumber' /usr/X11R6/lib/libXt.so.10.0: undefined reference to `SmcDeleteProperties' /usr/X11R6/lib/libXt.so.10.0: undefined reference to `IceProcessMessages' /usr/X11R6/lib/libXt.so.10.0: undefined reference to `SmcRequestSaveYourselfPhase2' /usr/X11R6/lib/libXt.so.10.0: undefined reference to `SmcInteractDone' /usr/X11R6/lib/libXt.so.10.0: undefined reference to `SmcCloseConnection' /usr/X11R6/lib/libXt.so.10.0: undefined reference to `SmcSetProperties' /usr/X11R6/lib/libXt.so.10.0: undefined reference to `SmcOpenConnection' /usr/X11R6/lib/libXt.so.10.0: undefined reference to `SmcInteractRequest' /usr/X11R6/lib/libXt.so.10.0: undefined reference to `SmcModifyCallbacks' /usr/X11R6/lib/libXt.so.10.0: undefined reference to `SmcClientID' /usr/X11R6/lib/libXt.so.10.0: undefined reference to `SmcGetIceConnection' That's because libxul.so is linked against some X libs (libXt needs libSM & libICE), and has RPATH set to /usr/X11R6/lib (in ldd output), but that rpath is not set in the build config for xpcshell|plugin-container link step. I don't know if it's a local build config issue, if XT_LIBS or XLIBS should bundle -lSM & libICE, but atm my workaround is to add -Wl,-rpath-link,/usr/X11R6/lib to LIBS in ipc/app/Makefile and js/src/xpconnect/shell/Makefile. This is definitely not a good fix so i'm looking for something better : - a real fix in my build env that i didn't found yet ? - add XLDFLAGS to LIBS as done in several places (browser/app/Makefile, layout/build/Makefile...) ? - globally add that -rpath-link dir to MOZ_FIX_LINK_PATHS ?
Comment 1•12 years ago
|
||
It looks like your problem is that libXt.so.10.0 is not linked against libSm and libICE, which would be a problem with your libXt build. FWIW, this is what Debian's libXt says: $ readelf -d /usr/lib/libXt.so.6 | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [libSM.so.6] 0x0000000000000001 (NEEDED) Shared library: [libICE.so.6] 0x0000000000000001 (NEEDED) Shared library: [libX11.so.6] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] You should see something similar. If you don't, your libXt is broken.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Assignee | ||
Comment 2•12 years ago
|
||
$ldd /usr/X11R6/lib/libXt.so.10.0 /usr/X11R6/lib/libXt.so.10.0: Start End Type Open Ref GrpRef Name 000000020c4b0000 000000020c911000 dlib 1 0 0 /usr/X11R6/lib/libXt.so.10.0 0000000200a0e000 0000000200e16000 rlib 0 1 0 /usr/X11R6/lib/libSM.so.8.0 0000000205741000 0000000205b5c000 rlib 0 2 0 /usr/X11R6/lib/libICE.so.9.0 0000000205b5c000 0000000206090000 rlib 0 1 0 /usr/X11R6/lib/libX11.so.14.0 0000000207fc4000 00000002083e0000 rlib 0 2 0 /usr/X11R6/lib/libxcb.so.2.2 00000002077e5000 0000000207be7000 rlib 0 3 0 /usr/X11R6/lib/libpthread-stubs.so.1.0 000000020ec96000 000000020f099000 rlib 0 3 0 /usr/X11R6/lib/libXau.so.9.0 0000000203d58000 000000020415d000 rlib 0 3 0 /usr/X11R6/lib/libXdmcp.so.10.0 $objdump -p /usr/X11R6/lib/libXt.so.10.0 | grep NEEDED NEEDED libSM.so.8.0 NEEDED libICE.so.9.0 NEEDED libX11.so.14.0 NEEDED libxcb.so.2.2 NEEDED libpthread-stubs.so.1.0 NEEDED libXau.so.9.0 NEEDED libXdmcp.so.10.0 libXt is correct.. however, libxul is not : $objdump -p /usr/local/lib/firefox-4.0/libxul.so.23.0 | grep NEED.*libX NEEDED libXrender.so.5.0 NEEDED libX11.so.14.0 NEEDED libXext.so.11.0 NEEDED libXxf86vm.so.5.0 NEEDED libXdamage.so.3.1 NEEDED libXfixes.so.5.0 NEEDED libXau.so.9.0 NEEDED libXdmcp.so.10.0 NEEDED libXinerama.so.5.0 NEEDED libXi.so.11.0 NEEDED libXrandr.so.6.1 NEEDED libXcursor.so.4.0 NEEDED libXcomposite.so.3.0 NEEDED libXt.so.10.0 To me, either XT_LIBS should be '-lXt -lSM -lICE', or libxul should be explicitely linked against SM and ICE (using X_PRE_LIBS, which contains -lSM -lICE in my config.status.. ??)
Status: RESOLVED → UNCONFIRMED
Ever confirmed: false
Resolution: INVALID → ---
Assignee | ||
Comment 3•12 years ago
|
||
Bah, i wanted to show that SM and ICE were not in NEEDED list.. grepping for libX wasnt the right way. $objdump -p /usr/local/lib/firefox-4.0/libxul.so.23.0 | egrep 'NEED.*(SM|ICE)' -> that returns nothing, so the dependency on those two libs is not recorded in libxul linking. Libxul finds them (by luck) at runtime because of $objdump -p /usr/local/lib/firefox-4.0/libxul.so.23.0 | grep RPATH RPATH /usr/X11R6/lib:/usr/local/lib/firefox-4.0
Comment 4•12 years ago
|
||
libxul doesn't directly use libSM and libICE symbols, so it doesn't need to directly link against them. If OpenBSD requires that, then its dynamic linker is broken. Your problem boils down to this: /usr/X11R6/lib is not in the default search path for libraries, and instead of doing so, you are self inflicting pain with an half broken setup. Your solution to the problem is to add an rpath so that libxul (and I guess anything else requiring X libraries) can find its dependencies in /usr/X11R6/lib. The secondary problem is that indirect dependencies (those that libxul DON'T need, but things it needs do, e.g. libSM through libXt) can't be found because the rpath is only on libxul, not libraries in /usr/X11R6/lib. So, in order for libSM and libICE to be found in /usr/X11R6/lib, you choose to use this rpath from libxul and link them to it. Well, this is bound to be a failure. Imagine one of the following (hypothetical) scenarios: - libSM changes SO version - libXt starts depending on /usr/X11R6/lib/libfoo.so In both cases, your libxul (and anything depending on libXt) will be broken by an updated libXt, while it really shouldn't need to be. So here is my advice: either add an rpath to all /usr/X11R6/lib libraries depending on other /usr/X11R6/lib libraries, or add /usr/X11R6/lib in the default search path. Or even better, do like linux distros, get rid of /usr/X11R6 (which, btw, is wrong, since we're using X11R7, now)
Assignee | ||
Comment 5•12 years ago
|
||
(In reply to comment #4) > libxul doesn't directly use libSM and libICE symbols, so it doesn't need to > directly link against them. If OpenBSD requires that, then its dynamic linker > is broken. > Your problem boils down to this: /usr/X11R6/lib is not in the default search > path for libraries, and instead of doing so, you are self inflicting pain with > an half broken setup. No, that's called 'control of dependencies'.. > So here is my advice: either add an rpath to all /usr/X11R6/lib libraries > depending on other /usr/X11R6/lib libraries, or add /usr/X11R6/lib in the > default search path. Changing system libs 'just for mozilla' is a no-go. After discussion with some of our devs, using -Wl,-rpath-link is the cleanest fix. So i've end up with adding '-Wl,-rpath-link,${X11BASE}/lib' to MOZ_FIX_LINK_PATHS in configure.in, which works. X11BASE is an environment variable during the build, and i didn't find another variable in existing XLDFLAGS,XLIBS,XCFLAGS & friends that could be used for it. $(x_libraries) is not propagated outside of configure.. Would it be considered an acceptable fix, likely to be commited ? > Or even better, do like linux distros, get rid of /usr/X11R6 (which, btw, is > wrong, since we're using X11R7, now) That's very unlikely to happen, and it's not that because all linux distros do it that it's a good idea :)
Comment 6•12 years ago
|
||
(In reply to comment #5) > No, that's called 'control of dependencies'.. No, that's called adding useless dependencies, and is doomed to fail. I'm actually surprised it didn't bring you pain already in the past. A typical case is with transitions, like when libpng changes soname, at which point with your scheme, you end up needing to rebuild everything, while there's only a need to rebuild a few intermediate libraries. > > So here is my advice: either add an rpath to all /usr/X11R6/lib libraries > > depending on other /usr/X11R6/lib libraries, or add /usr/X11R6/lib in the > > default search path. > > Changing system libs 'just for mozilla' is a no-go. It's not 'just for mozilla', that's the whole point. > After discussion with some of our devs, using -Wl,-rpath-link is the cleanest > fix. > So i've end up with adding '-Wl,-rpath-link,${X11BASE}/lib' to > MOZ_FIX_LINK_PATHS > in configure.in, which works. X11BASE is an environment variable during the > build, > and i didn't find another variable in existing XLDFLAGS,XLIBS,XCFLAGS & friends > that could be used for it. $(x_libraries) is not propagated outside of > configure.. > > Would it be considered an acceptable fix, likely to be commited ? If you put it in a openbsd specific part of configure.in, why not. OTOH, is your /usr/X11R6/lib rpath part of the mozilla build already ? If not, there's no point pushing half your "fix".
Assignee | ||
Comment 7•12 years ago
|
||
(In reply to comment #6) > (In reply to comment #5) > > No, that's called 'control of dependencies'.. > > No, that's called adding useless dependencies, and is doomed to fail. I'm > actually surprised it didn't bring you pain already in the past. A typical case > is with transitions, like when libpng changes soname, at which point with your > scheme, you end up needing to rebuild everything, while there's only a need to > rebuild a few intermediate libraries. We have a different scheme : we control all sonames, be it in the basesystem or in the libraries installed by ports. When updating packages, if an old library is still used by a package, it's kept on the system in a hidden package, and removed later when nothing uses it anymore. And bulk builds producing packages to be distributed to users are done on the whole ports tree, so the interdependencies are correct. > > After discussion with some of our devs, using -Wl,-rpath-link is the cleanest > > fix. > > So i've end up with adding '-Wl,-rpath-link,${X11BASE}/lib' to > > MOZ_FIX_LINK_PATHS > > in configure.in, which works. X11BASE is an environment variable during the > > build, > > and i didn't find another variable in existing XLDFLAGS,XLIBS,XCFLAGS & friends > > that could be used for it. $(x_libraries) is not propagated outside of > > configure.. > > > > Would it be considered an acceptable fix, likely to be commited ? > > If you put it in a openbsd specific part of configure.in, why not. OTOH, is > your /usr/X11R6/lib rpath part of the mozilla build already ? If not, there's > no point pushing half your "fix". it's part of some parts of the tree so it works for other sub libs 'by luck', through : X_LIBS, FT2_LIBS, XLDFLAGS and MOZ_CAIRO_LIBS containing -L/usr/X11R6/lib MOZ_GTK2_LIBS and MOZ_PANGO_LIBS containing -L/usr/X11R6/lib -R/usr/X11R6/lib -R is an equivalent as -rpath in this case.
Comment 8•12 years ago
|
||
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > No, that's called 'control of dependencies'.. > > > > No, that's called adding useless dependencies, and is doomed to fail. I'm > > actually surprised it didn't bring you pain already in the past. A typical case > > is with transitions, like when libpng changes soname, at which point with your > > scheme, you end up needing to rebuild everything, while there's only a need to > > rebuild a few intermediate libraries. > > We have a different scheme : we control all sonames, be it in the basesystem or > in the libraries installed by ports. > When updating packages, if an old library is still used by a package, it's kept > on the system in a hidden package, and removed later when nothing uses it > anymore. > And bulk builds producing packages to be distributed to users are done on the > whole ports tree, so the interdependencies are correct. Yay, even better, if you only rebuild half the system, you end up with 2 versions of a library in a process address space, all because one library or program that doesn't need it pulled the old version. With all the fun that comes with it. Anyways, this got offtopic. I'll stop here.
Assignee | ||
Comment 9•12 years ago
|
||
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > (In reply to comment #5) > > > > No, that's called 'control of dependencies'.. > > > > > > No, that's called adding useless dependencies, and is doomed to fail. I'm > > > actually surprised it didn't bring you pain already in the past. A typical case > > > is with transitions, like when libpng changes soname, at which point with your > > > scheme, you end up needing to rebuild everything, while there's only a need to > > > rebuild a few intermediate libraries. > > > > We have a different scheme : we control all sonames, be it in the basesystem or > > in the libraries installed by ports. > > When updating packages, if an old library is still used by a package, it's kept > > on the system in a hidden package, and removed later when nothing uses it > > anymore. > > And bulk builds producing packages to be distributed to users are done on the > > whole ports tree, so the interdependencies are correct. > > Yay, even better, if you only rebuild half the system, you end up with 2 > versions of a library in a process address space, all because one library or > program that doesn't need it pulled the old version. With all the fun that > comes with it. Just for clarification... only the correct version of the library is loaded in the process address space, as the dependency is recorded in the binary at link time with the needed version. Oh, and we don't have/need all the crazy symlinks in usr/lib. Like it or not, that's how OpenBSD is made, and mozilla builds/runs on it this way. I'm just trying to minimize the local changes i have.
Comment 10•12 years ago
|
||
Just for clarification, taking the example from this bug, considering your first suggestion to add -lSM -lICE when linking libxul: - libxul depends on libSM, libICE and libXt (but only uses symbols from the latter) - libXt depends on libSM and libICE. Now, imagine an upgrade of libSM's soname. You rebuild libXt but not libxul. libxul still depends on the old libSM (but doesn't use it), libXt depends on the new one. Result: both are loaded in the process address space when libxul is loaded, and symbols are very likely to resolve to the old libSM.
Assignee | ||
Comment 11•12 years ago
|
||
configure.in patch adds -Wl,-rpath-link,${X11BASE}/lib to MOZ_FIX_LINK_PATHS in the *-openbsd*) case. X11BASE is set in the environment by the portstree. It also changes DLL_SUFFIX to obey the environment variable SO_VERSION, which permits us to control the so versionning in the portstree. Don't know if this part is acceptable.
Comment 12•12 years ago
|
||
Comment on attachment 525057 [details] [diff] [review] add -Wl,-rpath-link,X11BASE/lib to MOZ_FIX_LINK_PATHS on OpenBSD >$OpenBSD: patch-configure_in,v 1.19 2011/03/30 21:39:14 landry Exp $ >https://bugzilla.mozilla.org/show_bug.cgi?id=648721 >--- configure.in.orig Sat Mar 19 00:33:33 2011 >+++ configure.in Mon Apr 11 10:48:46 2011 >@@ -2676,7 +2676,8 @@ ia64*-hpux*) > ;; > > *-openbsd*) >- DLL_SUFFIX=".so.1.0" >+ DLL_SUFFIX=".so.${SO_VERSION}" Make that '.so.$(if $(SO_VERSION),$(SO_VERSION),1.0)' >+ MOZ_FIX_LINK_PATHS='-Wl,-rpath-link,$(LIBXUL_DIST)/bin -Wl,-rpath-link,$(prefix)/lib -Wl,-rpath-link,${X11BASE}/lib' Make that depending on X11BASE being defined (though the same trick as above can't be used because of the commas)
Assignee | ||
Comment 13•12 years ago
|
||
Hah, that trick will be useful in more patches for SO_VERSION and others usages. Fixed patch, I hope that's what you meant for X11BASE defaulting to /usr/X11R6 if not defined, or rather adjust MOZ_FIX_LINK_PATHS only if ${X11BASE} is not empty ?
Attachment #525057 -
Attachment is obsolete: true
Comment 14•12 years ago
|
||
I meant removing the whole -rpath-link, but fair enough. I think you need to replace the double quotes with simple quotes for DLL_SUFFIX.
Assignee | ||
Comment 15•12 years ago
|
||
This time with single quotes, tested still building fine here and SO_VERSION is correctly applied.
Attachment #525059 -
Attachment is obsolete: true
Assignee | ||
Updated•12 years ago
|
Attachment #525070 -
Flags: review?(dtownsend)
Updated•12 years ago
|
Attachment #525070 -
Flags: review?(dtownsend) → review?(khuey)
Comment on attachment 525070 [details] [diff] [review] add -Wl,-rpath-link,X11BASE/lib to MOZ_FIX_LINK_PATHS on OpenBSD Mike seems to know what's going on here, and he's officially a peer now, so I'm punting this over to him.
Attachment #525070 -
Flags: review?(khuey) → review?(mh+mozilla)
Updated•12 years ago
|
Attachment #525070 -
Flags: review?(mh+mozilla) → review+
Assignee | ||
Updated•12 years ago
|
Assignee | ||
Updated•12 years ago
|
Blocks: openbsdmeta
Updated•12 years ago
|
Assignee: nobody → landry
Comment 17•12 years ago
|
||
Don't we want the same patch for js/src/configure.in?
Assignee | ||
Comment 18•12 years ago
|
||
It's currently not needed as it seems nothing under js/src links with X libs, but that could be good for the sake of consistency. Testbuilding the following diff against m-c with AC_DEFINE(AVMPLUS_UNIX) in openbsd case while here.
OS: OpenBSD → All
Assignee | ||
Comment 19•12 years ago
|
||
Attachment #526629 -
Flags: review?(mh+mozilla)
Comment 20•12 years ago
|
||
I will push the two patches when both will be reviewed. Let's remove the checkin-needed flag in the mean-time.
Keywords: checkin-needed
Comment 21•12 years ago
|
||
Comment on attachment 526629 [details] [diff] [review] same patch for js/src/configure.in, and ac_define(avmplus_unix) if target=openbsd > *-openbsd*) >- DLL_SUFFIX=".so.1.0" >+ DLL_SUFFIX='.so.$(if $(SO_VERSION),$(SO_VERSION),1.0)' this is going to get in the way of the real soname that is being applied to js releases. See bug 628723. >+ MOZ_FIX_LINK_PATHS='-Wl,-rpath-link,$(LIBXUL_DIST)/bin -Wl,-rpath-link,$(prefix)/lib -Wl,-rpath-link,$(if $(X11BASE),$(X11BASE),/usr/X11R6)/lib' you don't need that.
Attachment #526629 -
Flags: review?(mh+mozilla) → review-
Assignee | ||
Comment 22•12 years ago
|
||
(In reply to comment #21) > Comment on attachment 526629 [details] [diff] [review] > same patch for js/src/configure.in, and ac_define(avmplus_unix) if > target=openbsd > > > *-openbsd*) > >- DLL_SUFFIX=".so.1.0" > >+ DLL_SUFFIX='.so.$(if $(SO_VERSION),$(SO_VERSION),1.0)' > > this is going to get in the way of the real soname that is being applied to js > releases. See bug 628723. Yes, but remember, we (openbsd) override library versionning anyway, and we don't have the symlinks forest. And besides that, that chunk only sets the 'default value' for DLL_SUFFIX, from my understanding the real soname applied for js releases come on top of that later in configure.in. > >+ MOZ_FIX_LINK_PATHS='-Wl,-rpath-link,$(LIBXUL_DIST)/bin -Wl,-rpath-link,$(prefix)/lib -Wl,-rpath-link,$(if $(X11BASE),$(X11BASE),/usr/X11R6)/lib' > > you don't need that. Mh... then mounir, can you explain what you wanted in comment #17 ? For things to work fine for me, i only need the DLL_SUFFIX tweak to obey SO_VERSION if present in the env, and set AC_DEFINE(AVMPLUS_UNIX). (well that and https://bugzilla.mozilla.org/show_bug.cgi?id=589754 but that's a different issue)
Comment 23•12 years ago
|
||
(In reply to comment #22) > (In reply to comment #21) > > Comment on attachment 526629 [details] [diff] [review] > > same patch for js/src/configure.in, and ac_define(avmplus_unix) if > > target=openbsd > > > > > *-openbsd*) > > >- DLL_SUFFIX=".so.1.0" > > >+ DLL_SUFFIX='.so.$(if $(SO_VERSION),$(SO_VERSION),1.0)' > > > > this is going to get in the way of the real soname that is being applied to js > > releases. See bug 628723. > > Yes, but remember, we (openbsd) override library versionning anyway, and we > don't have the symlinks forest. > And besides that, that chunk only sets the 'default value' for DLL_SUFFIX, from > my understanding the real soname applied for js releases come on top of that > later in configure.in. You'll end up with libmozjs185.so.1.0.1.0 > > >+ MOZ_FIX_LINK_PATHS='-Wl,-rpath-link,$(LIBXUL_DIST)/bin -Wl,-rpath-link,$(prefix)/lib -Wl,-rpath-link,$(if $(X11BASE),$(X11BASE),/usr/X11R6)/lib' > > > > you don't need that. > > Mh... then mounir, can you explain what you wanted in comment #17 ? He asked if it was needed. Which it isn't. > For things to work fine for me, i only need the DLL_SUFFIX tweak to obey > SO_VERSION if present in the env Why do you want to override the so version of things that come with one ? > and set AC_DEFINE(AVMPLUS_UNIX). That should be a separate bug.
Assignee | ||
Comment 24•12 years ago
|
||
(In reply to comment #23) > (In reply to comment #22) > > (In reply to comment #21) > > > Comment on attachment 526629 [details] [diff] [review] > > > same patch for js/src/configure.in, and ac_define(avmplus_unix) if > > > target=openbsd > > > > > > > *-openbsd*) > > > >- DLL_SUFFIX=".so.1.0" > > > >+ DLL_SUFFIX='.so.$(if $(SO_VERSION),$(SO_VERSION),1.0)' > > > > > > this is going to get in the way of the real soname that is being applied to js > > > releases. See bug 628723. > > > > Yes, but remember, we (openbsd) override library versionning anyway, and we > > don't have the symlinks forest. > > And besides that, that chunk only sets the 'default value' for DLL_SUFFIX, from > > my understanding the real soname applied for js releases come on top of that > > later in configure.in. > > You'll end up with libmozjs185.so.1.0.1.0 And is it different from what we have right now ? I don't think so, since it defaults to 1.0. > > > >+ MOZ_FIX_LINK_PATHS='-Wl,-rpath-link,$(LIBXUL_DIST)/bin -Wl,-rpath-link,$(prefix)/lib -Wl,-rpath-link,$(if $(X11BASE),$(X11BASE),/usr/X11R6)/lib' > > > > > > you don't need that. > > > > Mh... then mounir, can you explain what you wanted in comment #17 ? > > He asked if it was needed. Which it isn't. Fine, disregard that part then. > > For things to work fine for me, i only need the DLL_SUFFIX tweak to obey > > SO_VERSION if present in the env > > Why do you want to override the so version of things that come with one ? As already said, the ports tree controls the so versionning. Things are this way. Do i argue about the symlink forest linux uses ? > > and set AC_DEFINE(AVMPLUS_UNIX). > > That should be a separate bug. https://bugzilla.mozilla.org/show_bug.cgi?id=650742
Comment 25•12 years ago
|
||
(In reply to comment #24) > > You'll end up with libmozjs185.so.1.0.1.0 > > And is it different from what we have right now ? I don't think so, since it > defaults to 1.0. Which is why you should set DLL_SUFFIX to .so, and either set SRCREL_VERSION in your ports, or override change Makefile.in to use SO_VERSION when there is one. You'll also need to modify Makefile.in to not create the "symlink forest". And since that all depends on release related changes from bug 628723, which I don't think have landed yet, you should file a new bug for that and CC Wes. Anyways, if you only build the js library as part of firefox build, it should be built statically.
Assignee | ||
Comment 26•12 years ago
|
||
(In reply to comment #25) > (In reply to comment #24) > > > You'll end up with libmozjs185.so.1.0.1.0 > > > > And is it different from what we have right now ? I don't think so, since it > > defaults to 1.0. > > Which is why you should set DLL_SUFFIX to .so, and either set SRCREL_VERSION in > your ports, or override change Makefile.in to use SO_VERSION when there is one. > You'll also need to modify Makefile.in to not create the "symlink forest". > > And since that all depends on release related changes from bug 628723, which I > don't think have landed yet, you should file a new bug for that and CC Wes. > Anyways, if you only build the js library as part of firefox build, it should > be built statically. Right, at some point in time (during the betas ?) i had libmozjs.so.X.Y installed but it seems it's not the case anymore with firefox 4. 628723 landed in the meantime, but we're not using js185 since it is broken on sparc64. I'll fill a separate bug for it when needed. In the meantime, readding checkin-needed for the first patch, the second patch can be discarded.
Keywords: checkin-needed
Comment 27•12 years ago
|
||
Pushed in cedar: http://hg.mozilla.org/projects/cedar/rev/ea5232835539
Status: NEW → ASSIGNED
Keywords: checkin-needed
Whiteboard: [fixed in cedar]
Version: unspecified → Trunk
Comment 28•12 years ago
|
||
Pushed to mozilla-central: http://hg.mozilla.org/mozilla-central/rev/ea5232835539
Status: ASSIGNED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Whiteboard: [fixed in cedar]
Target Milestone: --- → mozilla6
Updated•5 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•