Closed Bug 191447 Opened 17 years ago Closed 17 years ago

No support for gtk(X11) builds on OS X

Categories

(SeaMonkey :: Build Config, enhancement, P4)

PowerPC
macOS
enhancement

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.4alpha

People

(Reporter: hramrach, Assigned: netscape)

Details

Attachments

(5 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Darwin Power Macintosh; en-US; rv:1.1) Gecko/20021129
Build Identifier: Mozilla/5.0 (X11; U; Darwin Power Macintosh; en-US; rv:1.1) Gecko/20021129

Because of some OS X specific settinds hardcoded for target=Darwin and
cpu=powerpc it is impossible to build Mozilla for X11 on OS X.
I tried to switch to normal unix settings because without that some headers were
included but were not found.

Even with sane compiler options I had some problems
- the simple plugin (modules/plugin/samples/simple/libnpsimple.dylib) test did
not build (but I is probably not important) 
- the link of libgklayout.dylib in layout/build failed with
/usr/bin/ld: nsComputedDOMStyle.o has local relocation entries in non-writable
section (__TEXT,__const)

This is not Mozilla speceific but I have no idea what may cause this error.

Reproducible: Always

Steps to Reproduce:
-patch the build system to support X11 on OS X
.mozconfig:
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../obj-gtk-@CONFIG_GUESS@
mk_add_options RUN_AUTOCONF_LOCALLY=yes
mk_add_options MOZ_INTERNAL_LIBART_LGPL=yes
ac_add_options --enable-default-toolkit=gtk
ac_add_options --enable-toolkit-gtk
ac_add_options --enable-svg




OS X 10.1.5 dec 2001 dev tools. Carbon build is fine.
checkout on Jan 30
Didn't find dupes, has patch, marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Just curious:
Does 
-- snip --
./configure --enable-default-toolkit=xlib
gmake
-- snip --
work on OS X ?
Severity: normal → enhancement
Priority: -- → P4
Target Milestone: --- → mozilla1.4alpha
Comment on attachment 113197 [details] [diff] [review]
changes to configure/makefile to buid for X11

At a glance, the configure.in changes seem a bit excessive. I don't see the
need to move that entire toolkit check block just to enable x11 support for
darwin.  Also, the HOST_CFLAGS changes are unnecessary.  HOST_CFLAGS are used
when building host-targets when cross-compiling (forced for nsinstall &
mkdepend) so the previous toolkit checks do not apply.
Attachment #113197 - Flags: review-
#3: In addition to the above error I get
/usr/bin/ld: ns4xPluginInstance.o illegal reference to symbol: _XFlush defined
in indirectly referenced dynamic library /usr/X11R6/lib/libX11.6.dylib
while linking gkplugin.dylib

#4: HOST_CFLAGS: If they are used for nsinstall and mkdepend I do not see why
NO_X11 or XP_MACOSX is forced. But then it is probably really unneccessary to
change them.
I moved the toolkit check before C*FLAGS are determined because it does depend
on the selected toolkit. The no_x should be set based on widget toolkit(s), not
on target, and should be set before C*FLAGS (at least logically).

I do not really know what the author of the configure script had in mind. If you
are more knowledgeable, please enlighten me. 
I noticed that the fink patch for  Moz 1.1 does smaller change to the configure
script but it only changes hardcoded Carbon/OS X to hardcoded X11/Darwin which I
do not find acceptable. 
#3 means that you need to also explicitly link gkplugin.dylib against -lX11

#4: -DNO_X11 is set to tell mkdepend to not use X11 includes when building
mkdepend.  -DXP_MACOSX is just to tell whatever native programs we build that
the host/build machine is OSX.

no_x is not set by the toolkit.  no_x is set by the AC_PATH_X or AC_PATH_XTRA
macros which determine if you have X11 installed or not.  We use a separate
variable, NO_X11, to specify that we're not building with X11 support and that
is determined by toolkit.

I've run across that 'local relocation' error since this bug was filed and it's
caused by attempting to build a shared library with an object file/library that
was not compiled with -fPIC.  
Attachment #113197 - Attachment is obsolete: true
The build changes are fairly straight forward:
* Move the setting of OSX flags from the darwin platform default section to the
mac/cocoa toolkit section
* Add check for malloc.h to remove XP_MACOSX check from libical
* Use default unix configuration for plugins when not building mac (read
carbon) or cocoa widgets
* Only link against frameworks when building for mac/cocoa toolkits

The chrome changes will probably need some discussing:
* Made an executive decision that all x11 toolkits will use the unix
keybindings
* Added option to make-jars.pl & add-chrome.pl to force x11 (read unix)
defaults
(Mmmm, bugspam.)  FYI, there were a bunch of side-effects by removing the
XP_MACOSX & TARGET_CARBON defines to avoid linking against the framework libs. 
You're basically running the Darwin/FreeBSD/Unix X11 port.  Don't expect any of
the standard Mac behavior to work (like colon-delimited paths).  The profile is
stored in ~/.mozilla.  None of the Apple plugins will work.

The reason for the chrome changes is that we were doing the right thing and
checking for the mac/cocoa toolkit in the Makefiles to use the mac chrome but
the perl scripts were defaulting to mac chrome if the Darwin OS was detected. 
This caused certain chrome elements to not be defined properly and you would up
with a nice xul error in your browser window.

I tested this with --enable-default-toolkit=xlib and Apple's X11 server.  I
didn't test gtk because a) I didn't want to deal with fink tainting issues & b)
I didn't feel like compiling it.  (Btw, Roland, the bookmarks drop down menu
doesn't show the bookmarks but the bookmarks manager does.)
Attachment #115835 - Flags: review?(pavlov)
Attachment #115837 - Flags: review?(bryner)
Attachment #115835 - Flags: review?(pavlov) → review+
Attachment #115837 - Flags: review?(bryner) → review+
Oops.  Turns out that MOZ_X11 is the define set by the toolkit.  The NO_X11
define corresponds to no_x=yes which is autodetected by the autoconf macros. 
We've been using NO_X11 & MOZ_X11 interchangeably.  This patch fixes that.
Attachment #116161 - Flags: superreview?(sfraser)
Attachment #116161 - Flags: review?(peterl)
Attachment #116161 - Flags: review?(peterl) → review+
Attached patch xprint changes v1.0 (obsolete) — Splinter Review
*sigh* And because X11 is detected, we automatically enable xprint (even in a
non-X11 toolkit build).  I was under the impression that xprint was independent
of the toolkits so this patch compiles imgScaler.cpp is xprint is enabled and
fixes the link ordering issue.	If xprint shouldn't be enabled for non-X11
toolkits (Roland?), then the test should change.
Attachment #116161 - Flags: superreview?(sfraser) → superreview+
Christopher Seawood wrote:
> *sigh* And because X11 is detected, we automatically enable xprint (even in a
> non-X11 toolkit build).  I was under the impression that xprint was 
> independent of the toolkits so this patch compiles imgScaler.cpp is xprint
> is enabled and fixes the link ordering issue. 

imgScaler.cpp was required at the point as I realised that the raster driver and
some of HP's lowend PCL driver variants do not support server-side scaling
(PCL3, PCL5 and PCL6 drivers support server-side-scaling) and then the
application(=mozilla) has to do that job (older versions of mozilla's Xprint
module used it's own scaler code, newer versions use imgScaler.cpp to avoid code
duplication) ... ;-/

> If xprint shouldn't be enabled for non-X11
> toolkits (Roland?),

Well, there is the discussion whether Xprint should be supported under BeOS or
not, but I defer that discussion until someone from the BeOS folks file the bug
for that... :)
On second thought, only build xprint for X11 toolkits.
Attachment #116171 - Attachment is obsolete: true
The patches have been checked in.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
wow, it really builds almost out of the box this time.
I still need 
touch
obj-gtk-powerpc-apple-darwin6.4/modules/plugin/samples/simple/libnpsimple.dylib
to build:

c++ -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer-arith -Wcast-align -Woverloaded
-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-long-long -fpascal-strings
-traditional-cpp -fno-common -fshort-wc
har -pipe  -DNDEBUG -DTRIMMED -I/sw/include/gtk-1.2 -I/sw/include/glib-1.2
-I/sw/lib/glib/include -I/usr/X11R6/
include -fPIC -arch ppc -o libnullplugin.dylib  npshell.o nullplugin.o npunix.o
     -dynamiclib -install_name 
@executable_path/\libnullplugin.dylib -compatibility_version 1 -current_version
1 -L../../../../../dist/bin -lx
pcom -L../../../../../dist/bin
-L/sw/src/mozilla/obj-gtk-powerpc-apple-darwin6.4/dist/lib -lplds4 -lplc4 -lnspr
4 -lpthread  -lXt  -L/sw/lib -L/usr/X11R6/lib -lgtk -lgdk -lgmodule -lglib -ldl
-lintl -lXext -lX11 -lm -lm    
ld: warning dynamic shared library: /sw/lib/libgmodule.dylib not made a weak
library in output with MACOSX_DEPL
OYMENT_TARGET environment variable set to: 10.1
ld: warning dynamic shared library: /sw/lib/libglib.dylib not made a weak
library in output with MACOSX_DEPLOYM
ENT_TARGET environment variable set to: 10.1
ld: warning dynamic shared library: /sw/lib/libdl.dylib not made a weak library
in output with MACOSX_DEPLOYMEN
T_TARGET environment variable set to: 10.1
ld: warning dynamic shared library: /sw/lib/libintl.dylib not made a weak
library in output with MACOSX_DEPLOYM
ENT_TARGET environment variable set to: 10.1
ld: warning dynamic shared library: /usr/X11R6/lib/libXext.dylib not made a weak
library in output with MACOSX_
DEPLOYMENT_TARGET environment variable set to: 10.1
chmod +x libnullplugin.dylib
../../../../../config/nsinstall -L
/sw/src/mozilla/obj-gtk-powerpc-apple-darwin6.4/modules/plugin/samples/defau
lt/unix libnullplugin.dylib ../../../../../dist/bin/plugins
npsimple.cpp
c++ -o npsimple.o -c -DOSTYPE=\"Darwin6.4\" -DOSARCH=\"Darwin\" -DOJI
-I/sw/src/mozilla/mozilla/modules/plugin/
samples/simple/..
-I/sw/src/mozilla/mozilla/modules/plugin/samples/simple/../../public -I_xpidlgen
-I../../../.
./dist/include/xpcom -I../../../../dist/include/string
-I../../../../dist/include/plugin -I../../../../dist/inc
lude/widget -I../../../../dist/include/npsimple -I../../../../dist/include
-I/sw/src/mozilla/obj-gtk-powerpc-ap
ple-darwin6.4/dist/include/nspr      -I/usr/X11R6/include   -fPIC 
-I/usr/X11R6/include -fno-rtti -fno-exceptio
ns -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-long-long -fpascal-strings -traditional-cpp
-fno-common -fshort-wchar -pipe  -DNDEBUG -DTRIMMED -DWIDGET_DLL=\"lib
widget_gtk.dylib\" -DGFXWIN_DLL=\"libgfx_gtk.dylib\" -I/sw/include/gtk-1.2
-I/sw/include/glib-1.2 -I/sw/lib/gli
b/include -I/usr/X11R6/include -I/sw/include/gtk-1.2 -I/sw/include/glib-1.2
-I/sw/lib/glib/include -I/usr/X11R6
/include  -I/usr/X11R6/include -DMOZILLA_CLIENT -include
../../../../mozilla-config.h -Wp,-MD,.deps/npsimple.pp
 /sw/src/mozilla/mozilla/modules/plugin/samples/simple/npsimple.cpp
rm -f libnpsimple.dylib
c++ -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer-arith -Wcast-align -Woverloaded
-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-long-long -fpascal-strings
-traditional-cpp -fno-common -fshort-wc
har -pipe  -DNDEBUG -DTRIMMED -DWIDGET_DLL=\"libwidget_gtk.dylib\"
-DGFXWIN_DLL=\"libgfx_gtk.dylib\" -I/sw/incl
ude/gtk-1.2 -I/sw/include/glib-1.2 -I/sw/lib/glib/include -I/usr/X11R6/include
-I/sw/include/gtk-1.2 -I/sw/incl
ude/glib-1.2 -I/sw/lib/glib/include -I/usr/X11R6/include -fPIC -arch ppc -o
libnpsimple.dylib  npsimple.o      
-L../../../../dist/lib -lgtksuperwin -L../../../../dist/bin -lxpcom -L/sw/lib
-L/usr/X11R6/lib -lgtk -lgdk -lgm
odule -lglib -ldl -lintl -lXext -lX11 -lm  -Wl,-exported_symbols_list
-Wl,/sw/src/mozilla/mozilla/build/unix/gn
u-ld-scripts/components-export-list -bundle -lm    
ld: warning can't open dynamic library: @executable_path/libplds4.dylib
(checking for undefined symbols may be 
affected) (No such file or directory, errno = 2)
ld: warning can't open dynamic library: @executable_path/libplc4.dylib (checking
for undefined symbols may be a
ffected) (No such file or directory, errno = 2)
ld: warning can't open dynamic library: @executable_path/libnspr4.dylib
(checking for undefined symbols may be 
affected) (No such file or directory, errno = 2)
ld: Undefined symbols:
_PR_AtomicDecrement referenced from libxpcom expected to be defined in
@executable_path/libnspr4.dylib
_PR_AtomicIncrement referenced from libxpcom expected to be defined in
@executable_path/libnspr4.dylib
_PL_ArenaAllocate referenced from libxpcom expected to be defined in
@executable_path/libplds4.dylib
_PL_FinishArenaPool referenced from libxpcom expected to be defined in
@executable_path/libplds4.dylib
_PL_InitArenaPool referenced from libxpcom expected to be defined in
@executable_path/libplds4.dylib
_PR_FindSymbol referenced from libxpcom expected to be defined in
@executable_path/libnspr4.dylib
_PR_LoadLibrary referenced from libxpcom expected to be defined in
@executable_path/libnspr4.dylib
_PR_UnloadLibrary referenced from libxpcom expected to be defined in
@executable_path/libnspr4.dylib
_LL_Zero referenced from libxpcom expected to be defined in
@executable_path/libnspr4.dylib
_PR_snprintf referenced from libxpcom expected to be defined in
@executable_path/libnspr4.dylib
_PR_DestroyLock referenced from libxpcom expected to be defined in
@executable_path/libnspr4.dylib
_PR_Lock referenced from libxpcom expected to be defined in
@executable_path/libnspr4.dylib
_PR_NewLock referenced from libxpcom expected to be defined in
@executable_path/libnspr4.dylib
_PR_Unlock referenced from libxpcom expected to be defined in
@executable_path/libnspr4.dylib
...

Should I file a different bug for that?
I'm surprised that hasn't broken any Solaris builds.  The NSPR libs aren't
listed on the link line.  My guess is that they're being pulled in by shared
library dependencies on other platforms.  Change MOZ_COMPONENT_XPCOM_LIBS to
MOZ_COMPONENT_LIBS in that makefile and attach a patch when your build completes.
I tried the proposed variable change and make in modules/plugin finished
successfully.
Comment on attachment 116764 [details] [diff] [review]
npsimple build change

r=cls

That was the only place that needed to be changed?  The rest of the tree built
fine?
Attachment #116764 - Flags: review+
The npsimple patch has been checked in.
Good, now it shall build and render most pages
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.