GNOME Bugzilla – Bug 159814
building dia-0.94 on Solaris 8 using the Sun ONE Studio 7
Last modified: 2005-06-20 08:57:11 UTC
Hi, I'm attempting to build dia-0.94 on Solaris 8 using the Sun ONE Studio 7 compiler. There were a few issues where: 1) One needs to #include <ft2build.h> before #include <pango/pangoft2.h> in the following files lib/diagdkrenderer.c lib/dialibartrenderer.c lib/font.c However this may be caused by the fact that pango was built using an older version of the FreeType library, which has since been updated. 2) At some point the build process cannot find the fontconfig headers. This may be because Fonctconfig is installed in a "non-standard" location. However it referenced by pkgconfig: $ cat /usr/local/lib/pkgconfig/fontconfig.pc prefix=/usr/local/fontconfig-2.2.2 exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: Fontconfig Description: Font configuration and customization library Version: 2.2.2 Libs: -L${libdir} -lfontconfig Cflags: -I${includedir} $ 3) Sometimes <png.h> cannot be found or -lpng is missing (for linking in "app" directlry). I worked around these bugs by modifying Makefiles manually. 4) Command "make install" fails because variable 'omffile' is empty in files doc/*/Makefile and the shell fails (probably GNU Make runs Sun's Bourne shell /bin/sh instead of GNU's /bin/bash): for file in $(omffile); do ... After fixing these errors, there remain a few warnings you may want to fix. See attached log file. I'm omitting signed/unsigned issues as I doubt you'll want to fix or work around them.
Created attachment 34266 [details] parts of the build log
I do not about the developers but I only have limited access to some machines with Solaris 9 running Gnome 2.8 but I do not have access to Sun ONE Studio or the compiler suncc so it is very difficult for me to replicate let alone provide fixes for any of these issues (although 4) sounds like something I should take a closer look at). It would be extremely helpful if you could try and build Dia from CVS and see if these problems still exist and I am sure the developers would be very happy to accept any patches you could provide. I am trying to clear out Unconfirmed bug reports but I think I have no choice but to leave this one marked Unconfirmed.
We would certainly accept a patch to improve building on Solaris but tweaking to pass an unaccessible (for me) compilers warnings wont happen. Though I guess some of the warnings already got fixed cause they were cross compiler :-)
It's not about tweaking sources, it's about those warnings that point to real errors.
If you can help to track down those bugs or help educate me on how I might go about doing it (especially if I can do it without needing suncc) then it would be greatly appreciated. Thanks for making the effort of providing feedback, if I understood the problem better I really would like to help but our time and resources are scarce too.
Have you read the warning messages? My impression is that they're self-explanatory. For example: enum type mismatch: op "=" Different enums are used either part of = prototype: pointer to struct _Property [...] : "unknown", line 0 argument : pointer to struct _PropDescription [...] Protoype and definition of function are different. warning: dubious escape: \% I suspect \% should be %% or something like that. ...
Yes *I* have read the warnings. Many of them are either outdated casue the surrounding source has changed. Or they are alread fixed in cvs. Or they are harmless, i.e. tweaking, see Anachronism. Some showed real issues which I recently fixed. But in general dumping build logs into bugzilla isn't that useful. And casting away warnings just to have fewer of them usually isn't either. 2005-06-18 Hans Breuer <hans@breuer.org> * app/app_procs.c : const correctness for stderr_message_internal * app/dia-props.c : gtk_toggle_*() functions want GTK_TOGGLE_BUTTON not GTK_CHECK_BUTTON, also some G_CALLBACK casts * app/disp_callbacks.c : don't dereference the to the function call when the function pointer in meant to be checked against 0 * app/interface.c : warning fixes by using correct types * app/modify_tool.c : describe_props() members returns const pointer * app/render_libart.c : removed most of the render function again. They happily live in lib/dialibartrenderer.c since almost 3 years http://cvs.gnome.org/viewcvs/dia/app/render_libart.c?r1=1.31&r2=1.32 * lib/dia_dirs.c : dia_get_canonical_path() const correctness * lib/dia_svg.c lib/dia_xml.c : some char to xmlChar changes * lib/dialibartrenderer.c(set_line_join): actually set the join_style instead of the cap_style. Don't initialize Art* enums with GDK_* constants. Both mentioned in bug #159814 and not warned by most other compilers. * lib/diagtkfontsel.c : at least the watcom compiler did not like the trailing colon in the GtkTypeInfo initialization * lib/properties.c : avoid redefinition of LIBDIA_COMPILATION * lib/dialinechooser.c lib/diagdkrenderer.c : there may be a difference between char and gint8 * plug-ins/metapost/render_metapost.c : replace invalid escape \% with %% * plug-ins/wpg/wpg.c : consitently use guint8 * config.h.win32 : change HAVE_* defines to 1 not empty, avoids redefinition warnings for python and xslt plug-ins
I guess you'd rather have patches, but I don't see the point since most fixes are obvious. Also "dumping" build logs *is* useful, other projects such libxml2 are very happy when I provide logs, together with instructions for fixing the errors. You just have to read the warnings and look at the relevant lines in the relevant release. Now if the "dumped" logs were read and processed faster, they wouldn't be obsolete and useless... This is one reason I don't feel like providing patches since by the time you process them, sources would have changed so much that you'd tell me they're not that useful. Do you have a suggestion for helping?