0.43: make: wcstoimax() invalid conversion
Make fails for me building Inkscape-0.43. A full transcript of the log is below. The problem seems to be a series of invalid conversions from __gw<blah> to w<blah> in <inttypes.h>.
Here's my environment:
Libs: atkmm-1.6: 2.8.2 glibmm-2.4: 2.8.4 gtkmm-2.4: 2.8.2 pangomm-1.4: 2.8.2 sigc++-2.0: 2.0.17 atk: 1.10.1 cairo: 1.0.0 gconf-2.0: 1.2.1 glib-2.0: 2.8.4 gtk+-2.0: 2.8.6 gdk-2.0: 2.8.6 gdk-x11-2.0: 2.8.6 gtk+: 1.2.10 gdk: 1.2.10 orbit-2.0: 2.13.2 pango: 1.10.1 libxml-2.0: 2.6.22 freetype2: 9.8.3 gc6.5 gnome-vfs-2.0: 2.8.4 libbonobo-2.0: 2.13.1 bonobo-activation-2.0: 2.13.1 XFree86-4.5.0 Tools: gcc 3.4.3 glibc 2.2.4 autoconf 2.5.8 automake 1.9.6 libtool 1.5.20 bison-2.1 pkg-config-0.20
<config.h> has these: #define HAVE_INTTYPES_H 1 #define HAVE_STDDEF_H 1 #define HAVE_STDINT_H 1 #define HAVE_STDLIB_H 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_UNISTD_H 1 #define STDC_HEADERS 1
I fixed a vaguely similar problem compiling gnome-print-0.9 by adding #include <stdlib> to the failing .c file, but that doesn't seem to help this failure.
I'd appreciate any suggestions of where to focus my debugging efforts.
TIA,
Jim
-------------log of make:-------------------- Making all in src make[2]: Entering directory `/build/inkscape-0.43/src' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/X11R6/include/freetype2 \ -I/usr/X11R6/include -pthread -DORBIT2=1 -I/usr/local/include/gnome-vfs-2.0 \ -I/usr/local/lib/gnome-vfs-2.0/include \ -I/usr/local/include/bonobo-activation-2.0 \ -I/usr/local/include/libbonobo-2.0 -I/usr/local/include/gconf/2 \ -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include \ -I/usr/local/include/orbit-2.0 -I/usr/X11R6/include \ -I/usr/X11R6/include/freetype2 -DPOTRACE="potrace" -pthread \ -I/usr/local/include/gdkmm-2.4 -I/usr/local/lib/gdkmm-2.4/include \ -I/usr/local/include/glibmm-2.4 -I/usr/local/lib/glibmm-2.4/include \ -I/usr/local/include/pangomm-1.4 -I/usr/local/include/gtk-2.0 \ -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/sigc++-2.0 \ -I/usr/local/lib/sigc++-2.0/include -I/usr/local/include/glib-2.0 \ -I/usr/local/lib/glib-2.0/include -I/usr/local/include/pango-1.0 \ -I/usr/local/include/cairo -I/usr/local/include/gtkmm-2.4 \ -I/usr/local/lib/gtkmm-2.4/include -I/usr/local/include/atkmm-1.6 \ -I/usr/local/include/atk-1.0 -I/usr/local/include/libxml2 \ -I/usr/local/include -I../cxxtest -Wall -W -Wpointer-arith -Wcast-align \ -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter \ -march=pentium2 -O2 -pipe -MT arc-context.o -MD -MP -MF \ ".deps/arc-context.Tpo" -c -o arc-context.o arc-context.cpp; \ then mv -f ".deps/arc-context.Tpo" ".deps/arc-context.Po"; \ else rm -f ".deps/arc-context.Tpo"; exit 1; fi In file included from display/sp-canvas.h:28, from arc-context.cpp:26: /usr/include/inttypes.h: \ In function `intmax_t wcstoimax(const __gwchar_t*, __gwchar_t**, int)': /usr/include/inttypes.h:432: error: invalid conversion from \ `const __gwchar_t* __restrict' to `const wchar_t*' /usr/include/inttypes.h:432: error: initializing argument 1 of \ `long long int __wcstoll_internal(const wchar_t*, wchar_t**, int, int)' /usr/include/inttypes.h:432: error: invalid conversion from \ `__gwchar_t** __restrict' to `wchar_t**' /usr/include/inttypes.h:432: error: initializing argument 2 of \ `long long int __wcstoll_internal(const wchar_t*, wchar_t**, int, int)' /usr/include/inttypes.h: \ In function `uintmax_t wcstoumax(const __gwchar_t*, __gwchar_t**, int)': /usr/include/inttypes.h:451: error: invalid conversion from \ `const __gwchar_t* __restrict' to `const wchar_t*' /usr/include/inttypes.h:451: error: initializing argument 1 of \ `long long unsigned int __wcstoull_internal(const wchar_t*, wchar_t**, int, int)' /usr/include/inttypes.h:451: \ error: invalid conversion from `__gwchar_t** __restrict' to `wchar_t**' /usr/include/inttypes.h:451: error: initializing argument 2 of \ `long long unsigned int __wcstoull_internal(const wchar_t*, wchar_t**, int, int)' make[2]: *** [arc-context.o] Error 1
Make fails for me building Inkscape-0.43.
Can you try svn head or a recent snapshot?
While optimizing includes, I removed just the need for inttypes.h in sp-canvas.h so it all may compile on your system now. inttypes.h is still included by livarot, however, but let's see.
ralf
On Fri, Feb 03, 2006 at 9:44:15AM +0100, Ralf Stephan wrote:
Make fails for me building Inkscape-0.43.
Can you try svn head or a recent snapshot?
Ok, I just downloaded the latest snapshot I could find: 20060115-0840. I hope that's the latest effort.
While optimizing includes, I removed just the need for inttypes.h in sp-canvas.h so it all may compile on your system now. inttypes.h is still included by livarot, however, but let's see.
Success for the prior sp-canvas.h failure but it still fails, with the same msgs, at livarot. So it seems my configuration needs to lose inttypes.h altogether.
If you have any suggestions for a quick patch, I'll be happy to try another go at it. Or maybe I can learn enough by comparing sp-canvas.h between 0.43 and 20060115-0840, when I get some time...
Anyway, hope that info is useful.
Jim
------------from make log:--------------------------- In file included from livarot/LivarotDefs.h:11, from livarot/Path.h:13, from splivarot.h:10, from node-context.cpp:35: <same errors I reported earlier>
Success for the prior sp-canvas.h failure but it still fails, with the same msgs, at livarot. So it seems my configuration needs to lose inttypes.h altogether.
So I replaced the inttypes.h includes with ones for stdint.h in the remaining cases in svn. A patch is sent to you.
Hope it helps, ralf
Ralf Stephan <ralf@...748...> writes:
Success for the prior sp-canvas.h failure but it still fails, with the same msgs, at livarot. So it seems my configuration needs to lose inttypes.h altogether.
So I replaced the inttypes.h includes with ones for stdint.h in the remaining cases in svn. A patch is sent to you.
Hmm. I remember that some time back, I had to do it the other way around in order to get Inkscape working on Solaris (see http://wiki.inkscape.org/wiki/index.php/CompilingSunSolaris). The reference I found suggesting that inttypes.h is preferable is http://www.lns.cornell.edu/public/COMP/info/autoconf/Header-Portability.html
Cheers, Colin
Colin wrote
So I replaced the inttypes.h includes with ones for stdint.h in the remaining cases in svn. A patch is sent to you.
Hmm. I remember that some time back, I had to do it the other way around in order to get Inkscape working on Solaris (see http://wiki.inkscape.org/wiki/index.php/CompilingSunSolaris). The reference I found suggesting that inttypes.h is preferable is http://www.lns.cornell.edu/public/COMP/info/autoconf/Header-Portability.html
Thanks. Before patching again, I would like to know if it works on Jim's system and, if so, ask him to give us an #ifdef line to recognize his system.
ralf
On Feb 4, 2006, at 9:12 AM, Ralf Stephan wrote:
Thanks. Before patching again, I would like to know if it works on Jim's system and, if so, ask him to give us an #ifdef line to recognize his system.
To be a little more precise, we probably need things that we can use to get autoconf set, and get that to give us a feature define for inttypes.h vs. stdint.h
Hmmm... perhaps even searching for that might help.
On Sat, Feb 04, 2006 at 6:12:21PM +0100, Ralf Stephan wrote:
So I replaced the inttypes.h includes with ones for stdint.h in the remaining cases in svn. A patch is sent to you.
...
Before patching again, I would like to know if it works on Jim's system and, if so, ask him to give us an #ifdef line to recognize his system.
Ralf's patch seems to fix the compile problems from the invalid conversions related to the inttypes.h vs stdint.h issue. I have both inttypes.h and stdint.h on my system, which must be common since inttypes.h includes stdint.h. I thought those files came with libc, which in my case is glibc 2.2.4. I don't know offhand what the best "#ifdef line to recognize my system" would be, but I'll be happy to research the subject if someone can steer me in the right direction. :)
Unfortunately, the compile now fails at sp-item-group.cpp with the log below. My ancient glibc doesn't have a good gettext capability, so I have a separate libintl installed from gnu gettext-0.13. This all seems to be detected by autoconf: checking for ngettext in libc... no checking for bindtextdomain in -lintl... yes checking for ngettext in -lintl... yes checking for dgettext in -lintl... yes checking for bind_textdomain_codeset... yes checking for msgfmt... /usr/local/bin/msgfmt checking for dcgettext... yes checking for gmsgfmt... /usr/local/bin/msgfmt checking for xgettext... /usr/local/bin/xgettext
So, I'll stand by for further suggestions, patches, whatever.
Cheers,
Jim
---------make log:--------------------- ... sp-item-group.cpp; \ then mv -f ".deps/sp-item-group.Tpo" ".deps/sp-item-group.Po"; \ else rm -f ".deps/sp-item-group.Tpo"; exit 1; \ fi sp-item-group.cpp: In function `gchar* sp_group_description(SPItem*)': sp-item-group.cpp:390: error: `ngettext' undeclared (first use this function) sp-item-group.cpp:390: error: (Each undeclared identifier is reported only once for each function it appears in.) make[2]: *** [sp-item-group.o] Error 1
Ralf's patch seems to fix the compile problems from the invalid conversions related to the inttypes.h vs stdint.h issue. I have both inttypes.h and stdint.h on my system, which must be common since inttypes.h includes stdint.h. I thought those files came with libc, which in my case is glibc 2.2.4. I don't know offhand what the best "#ifdef line to recognize my system" would be, but I'll be happy to research the subject if someone can steer me in the right direction. :)
Given the problems you get with ngettext later, I'd say the 'right' thing for you to do would be to try a newer glibc version. A newer glibc would perhaps solve both the inttypes and the ngettext problem. However, that's probably a system upgrade.
Regarding ngettext, I'm at a loss: configure checks for it but does not define a macro for our case. According to
http://www.delorie.com/gnu/docs/gettext/gettext_190.html
the AM_GNU_GETTEXT macro with the needs-ngettext option should take care of it all. We have that in m4/gettext.m4 but defining it in configure.ac will not find it, and I don't even know if it could break our configure. I don't see an intl/ directory, either.
Who can help?
Regarding the right way of handling the stdint/inttypes case, Jon, I don't like fiddling with configure if it's just a glibc issue where we can use __GLIBC_MINOR__ etc. for discrimination of that case, but to prove it's glibc, either Jim has to upgrade or I'd have to reproduce the error somehow...
ralf
Regarding the right way of handling the stdint/inttypes case, Jon, I don't like fiddling with configure if it's just a glibc issue where we can use __GLIBC_MINOR__ etc. for discrimination of that case, but to prove it's glibc, either Jim has to upgrade or I'd have to reproduce the error somehow...
http://lists.gnu.org/archive/html/autoconf/2001-12/msg0034.html
So we know Jim's system now, and they were the only ones to include a buggy development version of glibc-2.2.4. Now if we had a macro that identifies Mandrake 8.1...
ralf
On Sun, Feb 05, 2006 at 10:41:54AM +0100, Ralf Stephan wrote:
Regarding the right way of handling the stdint/inttypes case, Jon, I don't like fiddling with configure if it's just a glibc issue where we can use __GLIBC_MINOR__ etc. for discrimination of that case, but to prove it's glibc, either Jim has to upgrade or I'd have to reproduce the error somehow...
http://lists.gnu.org/archive/html/autoconf/2001-12/msg0034.html
So we know Jim's system now, and they were the only ones to include a buggy development version of glibc-2.2.4. Now if we had a macro that identifies Mandrake 8.1...
As I write this, that URL seems to be dead ("...not found on this server"), but I'll take Ralf's remark to imply that he thinks I'm on a Mandrake 8.1 system. I'm actually on what was once a SuSE 7.3 system, before I upgraded Gcc, binutils, X, and most everything else except glibc, as it seems a bit more challenging upgrade, and up until now, hasn't been an issue. I'll keep trying that URL, as it sounds interesting, and I'll consider embarking on the glibc journey, but that may take a while.
After spending way too many hours working my way through SuSE 9.2 source code only to discover they'd hacked my SCSI driver beyond use, I decided my time would be better spent upgrading what I need, rather than debugging an unresponsive vendor's product.
This is the first gettext-related issue I've encountered. I had to set an environment variable, LIBS=-liconv, to get fontconfig to configure the link process properly, but nothing has had any compile issues with gettext.
Regarding glibc-2.2.4, here's what mine says to --version: Compiled by GNU CC version 2.95.3 20010315 (SuSE). Compiled on a Linux 2.4.9 system on 2001-09-20. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others Berkeley DB glibc 2.1 compat library by Thorsten Kukuk linuxthreads-0.9 by Xavier Leroy NoVersion patch for broken glibc 2.0 binaries BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Sounds like the test should be more glibc-specific rather than looking for Mandrake.
Cheers,
Jim
http://lists.gnu.org/archive/html/autoconf/2001-12/msg0034.html
one zero was missing, sorry:
http://lists.gnu.org/archive/html/autoconf/2001-12/msg00034.html
except glibc, as it seems a bit more challenging upgrade, and up until now, hasn't been an issue.
that may be due to inkscape but I don't know enough to point at the culprit of the ngettext issue. I will file a bug report for it.
sounds interesting, and I'll consider embarking on the glibc journey, but that may take a while.
It might suffice to upgrade to the next higher version, the actual fix for the inttypes problem might even be header only.
Sounds like the test should be more glibc-specific rather than looking for Mandrake.
Now that you revealed another system with that problem, I agree with Jon Cruz a test compile (like in the gnu.org list mail) after a check for glibc-2.2.4 is the best way to catch the inttypes issue.
ralf
Regarding ngettext, I'm at a loss: configure checks for it but does not define a macro for our case. According to
http://www.delorie.com/gnu/docs/gettext/gettext_190.html
the AM_GNU_GETTEXT macro with the needs-ngettext option should take care of it all. We have that in m4/gettext.m4 but defining it in configure.ac will not find it, and I don't even know if it could break our configure. I don't see an intl/ directory, either.
The solution to this is in bug issue #1244836: either you, again, upgrade glibc, or someone with a new glibc generates a source tarball for ou, or you only use the official source packages after we fixed that bug by upgrading the machine that creates the official inkscape sources.
Whose machine is this, anyway?
ralf
On Thu, Feb 09, 2006 at 10:26:49AM +0100, Ralf Stephan wrote:
Regarding ngettext, I'm at a loss: configure checks for it but does not define a macro for our case. According to
http://www.delorie.com/gnu/docs/gettext/gettext_190.html
the AM_GNU_GETTEXT macro with the needs-ngettext option should take care of it all. We have that in m4/gettext.m4 but defining it in configure.ac will not find it, and I don't even know if it could break our configure. I don't see an intl/ directory, either.
The solution to this is in bug issue #1244836: either you, again, upgrade glibc, or someone with a new glibc generates a source tarball for ou,
I'm working on upgrading glibc; since I'm moving from 2.2.4 instead of something older, maybe it won't be too dangerous. I try to be careful with things that might need a rescue floppy to recover from... :) So, it might be a while before I actually install the new lib.
I don't understand how generating a source tarball on a machine with a new glibc would solve a problem for a machine with an old glibc, but that just shows how much I have to learn about autoconf/automake and the library headers.
or you only use the official source packages after we fixed that bug by upgrading the machine that creates the official inkscape sources.
I don't get any hits on that bug number via google, but I'm confused: do you mean the bug is already "fixed" (by upgrading the machine...) or will hopefully be fixed someday when the official machine is upgraded? The latter interpretation makes more sense to me, but I want to be sure I'm understanding you correctly.
Whose machine is this, anyway?
Um, it's mine, and my wife's :). She's the eventual Inkscape user, (she's an artist) with me as tech support. At the moment, it's the only machine in the house, so I don't have the luxury of experimental installations without extreme care.
Is that what you meant by "Whose machine?"
Thanks for the info,
Jim
or you only use the official source packages after we fixed that bug by upgrading the machine that creates the official inkscape sources.
I don't get any hits on that bug number via google, but I'm confused: do you mean the bug is already "fixed" (by upgrading the machine...) or will hopefully be fixed someday when the official machine is upgraded? The latter interpretation makes more sense to me, but I want to be sure I'm understanding you correctly.
you understand correctly, and sorry if I was being unclear.
Whose machine is this, anyway?
Um, it's mine... Is that what you meant by "Whose machine?"
noo, I was fishing for the person that provides official tarballs or even snapshot tarballs to upgrade and add an option to configure.ac, so a different configure script will be generated so your and other problems will be solved.
ralf
participants (4)
-
Colin Marquardt -
Jim Osborn -
Jon A. Cruz -
Ralf Stephan