[sword-devel] -O3 -g

[Jonathan Marsden]

Troy A. Griffitts wrote:

>>   ./autogen.sh && ./usrinst.sh --disable-debug && make

>> displays all the warnings, so the current SWORD build environment is
>> actually turning *off* some warnings by default

> I'm not sure I understand why you are seeing this behavior.  You are
> correct that the *plan* was to -Wall -Werror for debug builds.  OK, I
> think I know now why....  If I comment out --enable-debug in usrinst.sh
> then things work as I would expect.  Without debug is the default, and
> --enable-debug is provided if you want otherwise.  I've never actually
> tried EXPLICITLY saying --disable-debug and I'm not sure why EXPLICITLY
> saying --disable-debug turns on your crazy warnings...  Is this some
> oddity with autoconf?

I'll try it commenting out --enable-debug in usrinst.sh.  No difference.
  For me it works the same commenting out --enable-debug and using
--disable-debug.  On Ubuntu 9.10 amd64, and on Fedora 12 amd64 (I
created a Fedora 12 VM, just for you :) , both ways of building SWORD
generate warnings, just as long as debug is turned off.

As indeed they should.  As GCC has, since at least 2007, for these
classes of coding error.  They are not "mine", and I don't think they
are "crazy" either :)  Please just fix the SWORD code to check return
values when it calls functions which are designed to sometimes return
error codes and which in some cases (notably write()) are designed to
have your code retry the write in such cases...

These warnings are happening on Debian, Ubuntu and Fedora 12 systems
just by commenting out the --enable-debug option in usrinst.sh, or by
using --disable-debug as a parameter to it.  On SWORD's current svn
tree.  I'm really not sure how much more I can do to demonstrate their
reality to you -- must I test on CentOS, OpenSuse and Mandriva too :)

I'm perfectly willing to work with you on better ways to check these
result values that meet your own coding standards, etc. etc. if my
patches do not measure up.  That's fine.  But telling that me these
warnings are "crazy" seems unwarranted and unhelpful (and frustrating)
at this point.

>> I'm not really sure *why* --disable-shared would be
>> considered "normal", by the way...?

> Cuz while developing I've been bitten too many times by trying to
> debug a problem with a binary pulling in the WRONG libsword.so.  I
> like to know my lib is linked directly in my binary to avoid this.

OK.  So again, that's "normal for SWORD developers" or "normal for
Troy", but not "general public normal" or "public release normal" :)

>>   I'm also not doing --libdir=/usr/lib64 which seems a very odd default.

> Aren't most systems running 64 bit these days?

I don't know, I suspect many Linux users still run 32bit.  Not all
Linuxes that are 64bit use this lib64 directory convention.  And some
(few) users run Linux (and so SWORD) on other architectures completely.

> Fedora uses /lib64 and /usr/lib64 by default on these systems, and
> Ubuntu at least symlinks /lib64 and /usr/lib64 to /lib and /usr/lib
> respectively, so we should be good on both distros with this.

I think it's ugly and unnecessary, and makes creating i386 packages
difficult.  It's probably fine for you, as a personal default.  It may
even be fine for most SWORD developers, if they all have 64bit machines.
 But not for "normal" or release builds, IMO.  Do remember, SWORD is
being built on hppa, mips, powerpc and s390 these days (I rather doubt
we have hordes of SWORD users on IBM s390, but the packages definitely
exist!).  Why make a path convention used by only some amd64 Linuxes the
default for all architectures??

>> Maybe usrinst.sh needs renaming to developerinst.sh (or even
>> troyinst.sh), making its target audience clear, and then a usrinst.sh
>> more aimed at real builds / real users can be created and included, too?

> :)

I'm serious -- developerinst.sh and usrinst.sh would provide both sets
of options for two different audiences, at very low cost to the project.
 Or developerinst.sh and releaseinst.sh , if you want to make a "clean
break" from the old (and apparently confusingly targetted) usrinst.sh.

Jonathan