After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 128163 - Possible problems with new XML parser
Possible problems with new XML parser
Status: RESOLVED FIXED
Product: intltool
Classification: Deprecated
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: intltool maintainers
intltool maintainers
Depends on:
Blocks:
 
 
Reported: 2003-11-29 12:17 UTC by Malcolm Tredinnick
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.5/2.6



Description Malcolm Tredinnick 2003-11-29 12:17:53 UTC
I am not completely sure that this is an intltool bug, but I suspect it
might be.

When building libgnomeprint from CVS using the latest intltool (CVS version
as of 1200 UTC on 29 Nov 2003), the build fails with an error like

LC_ALL=C ../../intltool-merge ../../po GNOME-GENERIC-PS.xml.in
GNOME-GENERIC-PS.xml -x -u -c ../../po/.intltool-merge-cache
Found cached translation database
Merging translations into GNOME-GENERIC-PS.xml.
Can't use string ("1") as an ARRAY ref while "strict refs" in use at
../../intltool-merge line 620.

The file GNOME-GENERIC-PS.xml.in does not look broken and has not changed
in a while.

In case it matters, I am building this on a Fedora box, so it is using
perl-libxml-perl version 0.07 to supply XML::Parser.
Comment 1 Kenneth Rohde Christiansen 2003-11-29 12:26:54 UTC
It is an intltool bug. But it is not happening for me. It happened for
me (on RH 9) when I changed ->Tree to ->OrigTree in
intltool-merge.in.in - I guess that is because it can't find the
OrigTree module which is distributed along with intltool. Maybe it
can't find the Tree module? Can you look into it? 
Comment 2 Malcolm Tredinnick 2003-12-01 00:17:28 UTC
I will try to work this out (except that I hate Perl). But in case I
get bogged down, I'll just make a note that it may not be only
Fedora-related.

Another Fedora report:
http://mail.gnome.org/archives/desktop-devel-list/2003-November/msg00563.html

and a Debian report:
http://mail.gnome.org/archives/desktop-devel-list/2003-November/msg00568.html

More news as it comes to hand. :-)
Comment 3 Kenneth Rohde Christiansen 2003-12-01 00:25:45 UTC
Fixed in cvs
Comment 4 Rob Adams 2003-12-01 03:31:22 UTC
this doesn't seem to work correctly.  intltool-merge ends up pushing
"/intltool" onto @INC instead of $datadir/intltool, apparently because
1) "$(datadir)" isn't the right syntax for variable deferencing (use
"${datadir}", 2) datadir isn't defined at that point anyway, so even
that doesn't work.
Comment 5 Malcolm Tredinnick 2003-12-01 04:02:31 UTC
This analysis (the previous comment) does not seem to be correct because

1) $(datadir) is the valid way to refer to variables in makefiles (see
http://www.gnu.org/software/make/manual/html_chapter/make_6.html#SEC66,
for example) , and

2) $(datadir) *is* defined at the point intltool-merge is created from
intltool-merge.in (it is defined very early on in the Makefile) and 3)
doing a clean build from CVS puts the right values in there when I
tried it just now.

Rob, have a look in your generated Makefile. Is datadir set to anything?

Comment 6 Kenneth Rohde Christiansen 2003-12-01 23:56:24 UTC
Should be fixed now. Please test!
Comment 7 Malcolm Tredinnick 2003-12-07 03:16:31 UTC
Rob: ping...

Does this work for you now? Can we close it?

(probably a good idea to add yourself to the CC list of a bug you
reopen so that we can get feedback.)
Comment 8 Rob Adams 2003-12-07 03:48:04 UTC
yea, works great.  Good job!