Re: [Bug-apl] errors building gnu-apl 1.7

[Dr . Jürgen Sauermann]

Hi Jeff,

sorry, my fault. You should actually set modulename to trunk and then only
the trunk is being checked out.

If you leave modulename empty (as I incorrectly proposed) then you get
all GNU APL versions ever committed, which is much more than what
you need to build the latest version.

So yes, change to directory trunk and build there. You can safely delete the
'tags' and 'branches' directories.

Best Regards,
/// Jürgen


On 4/25/19 3:23 AM, Jeff Derby wrote:
> Jürgen,
>
> thanks very much for the response.  the Apple tools use clang, and it
> may be that clang used as gcc (or g++) is much more picky than gcc (or
> g++) itself
>
> i did 'svn co svn://svn.savannah.gnu.org/apl' (so apparently with an
> empty modulename)
> so i have subdirectories for apl-1.0 through apl-1.7, and one for
> 'trunk'.  
> do i build in the 'trunk' subdirectory?
>
> thanks
>
> Jeff H. Derby
> Senior Technical Staff Member
> Next Generation Computing
> IBM Research
> ------
> IBM Corporation
> RTP, NC  USA
> Cell: (919) 672-0962
> Internet: address@hidden
>
>
>
> From:        "Dr. Jürgen Sauermann" <address@hidden>
> To:        Jeff Derby <address@hidden>, address@hidden
> Date:        04/24/2019 12:45
> Subject:        Re: [Bug-apl] errors building gnu-apl 1.7
> ------------------------------------------------------------------------
>
>
>
> Hi Jeff,
>
> the warning regarding *-Wconstant-logical-operand*is bogus. I have
> nevertheless
> updated the sources; the line now reads:
> *
> ostream * log = (LOG_startup != 0 || LOG_Svar_DB_signals != 0) ? &
> cerr : 0;*
>
> You can either fix that line manually, or update to the latest SVN
> version 1138 where the
> line is corrected.
>
> The sirst two warnings (*-Wnull-dereference*) are a little obscure
> since the indicated
> line numbers in *ScalarFunction.cc* do not show anything close to the
> printout of the error.
>
> This could have two reasons:
>
> A. you compile a rather old version of GNU APL (for examle the one
> stored on the GNU mirrors).
> In that case I would recommend to fetch the GNU APL code from our SVN
> repository at savannah
> (see _https://savannah.gnu.org/svn/?group=apl_with an empty modulename).
>
> B. your compiler expands some macros somewhere and displays the
> expaneded text while
> loosing track of the source code lines. In that case I would disable
> this particular warning
> (reconfigure the sources with something like:
> *
> CXXFLAGS = -Wnonull-dereference ./configure*
>
> ). I believe these 2 warning are also not significant.
>
> Best Regards,
> Jürgen
>
>
> On 4/24/19 5:01 PM, Jeff Derby wrote:
> this was on a Mac running macOS 10.14.4 using Apple's command line tools:
> -----------------
> l-Svar_record.o `test -f 'Svar_record.cc' || echo './'`Svar_record.cc
> ScalarFunction.cc:97:14: error: binding dereferenced null pointer to
> reference has undefined behavior [-Werror,-Wnull-dereference]
>    : value_Z(*(Value *)0),
>              ^~~~~~~~~~~
> ScalarFunction.cc:159:14: error: binding dereferenced null pointer to
> reference has undefined behavior [-Werror,-Wnull-dereference]
>    : value_Z(*(Value *)0),
>              ^~~~~~~~~~~
> 2 errors generated.
> make[3]: *** [apl-ScalarFunction.o] Error 1
> make[3]: *** Waiting for unfinished jobs....
> Svar_DB.cc:302:30: error: use of logical '||' with constant operand
> [-Werror,-Wconstant-logical-operand]
> ostream * log = (LOG_startup || LOG_Svar_DB_signals) ? & cerr : 0;
>                              ^  ~~~~~~~~~~~~~~~~~~~
> Svar_DB.cc:302:30: note: use '|' for a bitwise operation
> ostream * log = (LOG_startup || LOG_Svar_DB_signals) ? & cerr : 0;
>                              ^~
>                              |
> 1 error generated.
> make[3]: *** [apl-Svar_DB.o] Error 1
> mv -f .deps/apl-StateIndicator.Tpo .deps/apl-StateIndicator.Po
> mv -f .deps/apl-Svar_record.Tpo .deps/apl-Svar_record.Po
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> ---------------
>
> should i just turn off treating warnings as errors?
>
> thanks
>
> Jeff H. Derby
> IBM Corporation
> RTP, NC  USA
> Cell: (919) 672-0962
> Internet: address@hidden <mailto:address@hidden>
>
>
>