The Blue Meanie wrote:
> First, I had to get and install gnu make.  Sun's make just didn't want to deal
> with the provided Makefiles.

Maybe you could show us the first error messages from make. The Makefiles
don't look as if they require GNU make here. I don't use GNU make to
build it.

> Second, I had to manually edit the config.sh to undef all the
> 'sendfile'-related stuff.  Sun's sendfile is rather b0rken, and I know that,
> so I knew I'd have to do this.

What do you mean with broken?

> The only follow-up here is that it might be
> nice to have a manual override in the configure that would let me turn
> sendfile usage off without manual editing.

That's possible for every item in config.sh. In this case you'd use

        ./Configure -Oders -Ud_sendfile

to undefine the d_sendfile symbol i.e., to override the detection
result.

> In src/main.c, line 516, there's a call to "raise(SIGTRAP)".

This code is in an "#if 0 ... #endif" block, thus not used.

> For some reason,
> while compiling src/core/downloads.c, I get a compile-time warning at line
> 6261 about "implicit function declaration: raise" and "undefined symbol:
> SIGTRAP".

This should be fixed in CVS since signal.h is included in common.h, thus
all such symbols are available from all files.

> In src/core/gwcache.c, on line 297, my compiler insists that 'left operand
> must be modifiable lvalue: op "="'.  I was therefore forced to change line 297
> to:
>        file_path_t fpvec[] = {
> (losing the "const") to eliminate this complaint and move forward.  This also
> doesn't seem to have had any ill effects.

Thanks, I've removed it now.

> In src/core/tx.c, at line 198, there's a return called from within a void
> function.  My compiler nixed that idea completely, so I had to lose the
> return:
>         TX_FLUSH(tx);

Dito. It's somewhat strange that GCC doesn't emit a warning for that.

> In src/ui/gtk/gtk2/interface-glade.c, line 12672 makes a call to
> gtk_alignment_set_padding().  This is a new function in GTK 2.4.x, and I still
> have 2.2.x installed.

This had been fixed a while ago in CVS as well. The current code
should compile fine with GTK+ 2.0 but as I've installed 2.6 I won't
guarantee that.

> Finally, in src/lib/misc.c, at line 722, my compiler seems to have issues with
> the ': (g_assert_not_reached(), -1)' construct, reporting a "syntax error:
> empty declaration" at the "if".

That might not be valid code if you don't use GCC due to the way the
g_assert() et al. macros are defined. GLib uses different macro wrappers
for different compilers. Obviously, an "if" is not allowed there by
standard C, GCC has an extension to use nested C code.

I've fixed this now.

> The last little problem cropped up when I closed GTKG down.  It left a core
> due to a segfault during the shutdown procedure.

It's unlikely to be the last problem. The code from CVS has a lot
of bugs fixed. Anyone who compiles from sources anyway should use
CVS at least currently. There should have been a bugfix release by
now but there wasn't because nobody's time for that.

-- 
Christian

Attachment: pgpQ9RnKt4tC4.pgp
Description: PGP signature

Reply via email to