-
Two different files in the libgpod-0.6.0 distribution have a haystack() function declared auto and nested inside another function. The Sun compiler on Solaris errors out on this. To fix, I just moved each function outside of the function it was nested in and declared it static. Patch to accomplish this is attached. With this patch and the previous two I sent, libgpod 0.6.0 builds on Solaris...
2008-11-21 23:36:26 UTC in GUI for iPod using GTK2 (gtkpod)
-
In libgpod-0.6.0/src/db-parse-context.h, the prototype for *just* db_parse_context_get_remaining_length has G_GNUC_INTERNAL both before the function proto and after. None of the other protos have this -- in all the other cases, G_GNUC_INTERNAL is just before the proto.
If you're using a compiler other than gcc (I'm using Sun Workshop Express 07/2008 on Solaris 10), the G_GNUC_INTERNAL may...
2008-11-21 23:30:16 UTC in GUI for iPod using GTK2 (gtkpod)
-
configure.in for libgpod-0.6.0 forces -Wall into CFLAGS. It's much better to test to see if gcc is the compiler first, and then add -Wall if it is. That way, it doesn't break things if you're using a compiler other than gcc.
Trivial patch is attached.
2008-11-21 23:23:53 UTC in GUI for iPod using GTK2 (gtkpod)
-
Setting CC=CC does work around most of the issue. There's still the problem that CFLAGS are being passed to the C++ compiler, and not all of them are valid for the C++ compiler, but that's a less critical problem.
I'm also getting a build error, but I'll investigate that further and open a separate report if
necessary.
Thanks.
2008-05-06 21:21:37 UTC in wxWidgets
-
It doesn't appear that's the case:
$ python setup.py build_ext USE_SWIG=0 CXX=CC --inplace
WARNING: WXWIN not set in environment. Assuming '..'
Found wx-config: /local/bin/wx-config
Using flags: --toolkit=gtk2 --unicode=yes --version=2.8
Preparing CORE...
Preparing GLCANVAS...
Preparing STC...
Preparing GIZMOS...
invalid command name 'CXX=CC'
$CXX=CC python setup.py...
2008-05-05 23:43:13 UTC in wxWidgets
-
I'm trying to build wxPython 2.8.7.1 on x86_64-sun-solaris2.10. I have the Sun Workshop 12 C and C++ compilers installed, and those are the compilers that were used to build python 2.4.5.
Whether I download wxWidgets 2.8.7 separately and build and install that first, or I use the wxWidgets that comes with wxPython 2.8.7.1, wxWidgets builds correctly using the Sun C++ compiler.
The problem...
2008-05-05 20:34:06 UTC in wxWidgets
-
I ran into this exact same problem with the latest Sun compilers (Workshop 12 + all patches). The macros essentially expand to
static void test_fail_empty ( int _i __attribute__ ( ( unused ) ) ) { tcase_fn_start ( "" "test_fail_empty" , "check_check_sub.c" , 105 ) ;
{
_fail_unless ( 0 , "check_check_sub.c" , 107 , "Failed" , , 0L );
}
}
and the compiler doesn't like the , ...
2008-02-19 23:14:02 UTC in check
-
I'm experimenting with papi-1.0_beta on x86_64-sun-solaris2.10.
When you "make install", papi's install procedure
installs headers named (among some less-problematic names)
debug.h
http.h
These are installed into the top level of the include directory (${prefix}/include).
This strikes me as a very bad idea, because the header file names are very common (they could easily have...
2007-12-30 23:02:41 UTC in OpenPrinting
-
I'm building on x86_64-sun-solaris2.10, with the latest Sun compilers, from the Sun Workshop 12 bundle, with all patches applied.
I get a compile error in libdjvu, for ddjvuapi.cpp:
gmake[1]: Entering directory `/local/src/RPM/BUILD/djvulibre-3.5.20/libdjvu'
gmake[1]: Circular Makefile.dep
2007-12-24 17:31:58 UTC in DjVuLibre
-
When doing an install (I'm on x86_64-sun-solaris2.10, but that doesn't matter in this case) in the doc/html
directory, the install-data-local fails for the API documentation.
This happens because of the way that the install-data-local target is written. The target references $(INSTALL_DATA), which will likely be a relative path, but it tries to do so in a command that cd's into the api...
2007-11-30 21:46:14 UTC in FLAC-Free Lossless Audio Codec
