234185 - Build failure: #error "No SVG renderer."

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Vincent Lefevre]

User-Agent:       
Build Identifier: 

I can no longer compile Mozilla (from the CVS). I get the following error:

[...]
nsSVGOuterSVGFrame.cpp:235: warning: `visibility' attribute directive ignored
nsSVGOuterSVGFrame.cpp:317:2: #error "No SVG renderer."
{standard input}: Assembler messages:
{standard input}:8: Warning: setting incorrect section attributes for
.text._ZN17VMRectInvalidatorC2EP14nsIViewManagerP7nsIViewi
[...]
make[6]: *** [nsSVGOuterSVGFrame.o] Error 1
make[6]: Leaving directory
`/home/lefevre/software/moz-source/mozilla/layout/svg/base/src'
make[5]: *** [libs] Error 2
make[5]: Leaving directory
`/home/lefevre/software/moz-source/mozilla/layout/svg/base'
make[4]: *** [libs] Error 2
make[4]: Leaving directory `/home/lefevre/software/moz-source/mozilla/layout/svg'
make[3]: *** [libs] Error 2
make[3]: Leaving directory `/home/lefevre/software/moz-source/mozilla/layout'
make[2]: *** [libs] Error 2
make[2]: Leaving directory `/home/lefevre/software/moz-source/mozilla'
make[1]: *** [alldep] Error 2
make[1]: Leaving directory `/home/lefevre/software/moz-source/mozilla'
make: *** [alldep] Error 2

Reproducible: Always
Steps to Reproduce:
1. n/a
Actual Results:  
n/a

Expected Results:  
n/a

Here's my .mozconfig:

# Perl program (Mozilla takes perl5 by default, which can lead to clashes)
PERL=perl

# Options for 'configure' (same as command-line options).
ac_add_options --prefix=$HOME/mozilla
ac_add_options --with-system-jpeg
ac_add_options --with-system-zlib
ac_add_options --with-system-png
ac_add_options --with-system-mng
ac_add_options --enable-calendar
ac_add_options --enable-xft
ac_add_options --enable-crypto
ac_add_options --disable-debug
ac_add_options --enable-optimize=-O2
ac_add_options --enable-reorder
ac_add_options --enable-strip
ac_add_options --enable-xterm-updates

# SVG support - see http://www.mozilla.org/projects/svg/build.html
ac_add_options --enable-svg
mk_add_options MOZ_INTERNAL_LIBART_LGPL=1
MOZ_INTERNAL_LIBART_LGPL=1

Comment 1

[Alex Fritze]

Now that the svg development branch has landed, you need to specify a renderer
in your .mozconfig, in your case:

ac_add_options --enable-svg-renderer-libart

See http://www.mozilla.org/projects/svg/build.html for details.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Would it make sense to do the check that a renderer has been defined at
configure time, though?  Getting most of the way through a build only to have to
restart really sucks...

Reopening this to implement that suggestion (but feel free to wontfix if you
think the current situation is fine, I guess).

Comment 3

[Alex Fritze]

Sounds like a good idea. 
Do you reckon a check if at least one '--enable-renderer-XXX' has been specified
is enough?

Comment 4

[Boris Zbarsky [:bzbarsky]]

Yeah, that should be sufficient.  After all, that's all this #error is testing, no?

I'd still leave the #error in for people who choose not to use configure somehow....

Comment 5

[Vincent Lefevre]

How about having a default renderer? (In particular if there is only one
renderer available, as this seems to be the case under Linux.)

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

actually, linux now has the choice between cairo and libart

but I'd also find it a good idea if there was a default rednerer

Comment 7

[Jonathan Watt [:jwatt]]

Mass reassign of SVG bugs that aren't currently being worked on by Alex to
[e-mail]. If you think someone should be assigned to your bug you can
join the #svg channel on mozilla.org's IRC server ( irc://irc.mozilla.org/svg )
where you can try to convince one of the SVG hackers to work on it. We aren't
always there, so if you don't get a response straight away please try again later. 

Comment 8

[Alex Vincent [:WeirdAl]]

Per the code in nsSVGOuterSVGFrame.cpp::Init(), only one of the three renderers
is allowed.  Therefore, the configure script should do a count of the options,
and throw an error if the value isn't one.

I'm willing to fix this bug; it broke my build.  I don't know shell programming
yet, but I'm sure I can find some way to fix this.  If someone can show me how a
shell script like ./configure can hold an integer value as a variable, then I
can just tally up a total there and check the total.  Otherwise, you'll get a
convoluted set of if statements.

Comment 9

[Vincent Lefevre]

I don't know if all sh shells can do arithmetic evaluation (remember that some
OS'es, like Solaris, do not have a POSIX shell as /bin/sh). The best way is to
do a string test anyway. For instance, initialize with:

renderer=unset

When a renderer option is used:

if test $renderer = set; then
  # error code
fi
renderer=set
# code corresponding to the option

Comment 10

[Vincent Lefevre]

Hmm... you may want to accept twice the same renderer option. So, something like
that would be better, where $option contains the option value:

if test $renderer = unset; then
  renderer=$option
  # ...
elif test $renderer != $option; then
  # error code
fi

Comment 11

[Alex Vincent [:WeirdAl]]

Attachment: patch, v1

A rather elegant solution, based on code around that particular fragment.  I am
not qualified to hack the configure script; this was largely just a little
logic.

Tested it, and it works.

Comment 12

[Alex Vincent [:WeirdAl]]

Taking.

Comment 13

[Alex Vincent [:WeirdAl]]

Comment on attachment 161545 [details] [diff] [review]
patch, v1

per bz's advice, r? bsmedberg

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 161545 [details] [diff] [review]
patch, v1

you can't hack configure directly. it's a generated file - your changes would
be overwritten once it's regenerated. change configure.in instead.

Comment 15

[Alex Vincent [:WeirdAl]]

Attachment: patch, v2

bsmedberg expressed reservations about approving a patch disallowing more than
one  svg renderer.  I feel we should disallow it based on the current code, but
we need a judgment call from afri on that.

In any case, this patch disallows having zero svg renderers.  The patch is to
configure.in, per biesi's comment.

Comment 16

[Benjamin Smedberg]

Comment on attachment 161582 [details] [diff] [review]
patch, v2

It's getting closer ;)

instead of echo "configure: ", you need to use AC_MSG_ERROR:

AC_MSG_ERROR([Must choose a SVG renderer if SVG is enabled.])

also, remove the redundant test -n $MOZ_SVG since it is unneeded

Comment 17

[Alex Vincent [:WeirdAl]]

Attachment: patch, v2.1

answering bsmedberg's concerns

Comment 18

[Alex Vincent [:WeirdAl]]

I cannot check this in.  Would someone do the honors, please?

Comment 19

[Stef van der Made]

I'm still getting this error after applying the patch:

+++ updating chrome ../../../../../../dist/bin/chrome/installed-chrome.txt
+++     content,install,url,jar:resource:/chrome/comm.jar!/content/xbl-marquee/
+++ making chrome
/usr/download/garnome-2.8.0.1/bootstrap/mozilla/work/main.d/mozilla/layout/html/forms/src
 => ../../../../dist/bin/chrome/en-US.jar
nsSVGOuterSVGFrame.cpp
nsSVGOuterSVGFrame.cpp:321:2: #error "No SVG renderer."

In the directory 
/usr/download/garnome-2.8.0.1/bootstrap/mozilla/work/main.d/mozilla/layout/svg/base/src
The following command failed to execute properly:
ccache g++ -o nsSVGOuterSVGFrame.o -c -DOSTYPE="Linux2.6" -DOSARCH="Linux"
-D_IMPL_NS_LAYOUT -I./../../../base/src -I./../../../html/table/src
-I./../../../html/style/src -I./../../../html/base/src
-I./../../../html/forms/src -I./../../../../content/svg/content/src
-I./../../../html/content/src -I./../../../xml/content/src
-I./../../../base/public -I../../../../dist/include/xpcom
-I../../../../dist/include/string -I../../../../dist/include/content
-I../../../../dist/include/gfx -I../../../../dist/include/widget
-I../../../../dist/include/dom -I../../../../dist/include/locale
-I../../../../dist/include/view -I../../../../dist/include/pref
-I../../../../dist/include/necko -I../../../../dist/include/unicharutil
-I../../../../dist/include/webshell -I../../../../dist/include/layout
-I../../../../dist/include
-I/usr/download/garnome-2.8.0.1/bootstrap/mozilla/work/main.d/mozilla/dist/include/nspr
-I/usr/X11R6/include -fPIC -I/usr/test/garnome/include -I/usr/X11R6/include
-I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-non-virtual-dtor -Wno-long-long -I/usr/test/garnome/include
-I/usr/X11R6/include -L/usr/test/garnome/lib -L/usr/X11R6/lib -O2 -pipe
-falign-functions=4 -mfancy-math-387 -march=athlon-tbird -m3dnow -fshort-wchar
-pthread -pipe -DNDEBUG -DTRIMMED -O -I/usr/test/garnome/include
-I/usr/X11R6/include -I/usr/X11R6/include -DMOZILLA_CLIENT -include
../../../../mozilla-config.h -Wp,-MD,.deps/nsSVGOuterSVGFrame.pp
nsSVGOuterSVGFrame.cpp

I'm compiling mozilla-1.8a4 + attachment 161585 [details] [diff] [review] (patch V2.1) for this bug and
attachment 159844 [details] [diff] [review] fixing issues with freetype 2.1.9
using gcc-3.4.2,glibc-2.3.2,kernel-2.6.9-rc4 to compile 

Comment 20

[Alex Vincent [:WeirdAl]]

Did you run autoconf after applying the patch?  The patch works on configure.in,
not the actual configure script.  This is per biesi's instructions not to patch
configure.

Comment 21

[Ian Neal]

Checking in configure.in;
/cvsroot/mozilla/configure.in,v  <--  configure.in
new revision: 1.1374; previous revision: 1.1373
done

Comment 22

[Alex Vincent [:WeirdAl]]

Marking fixed per comment 21.