This change will not affect any existing users. 2017-03-10 8:54 GMT+01:00 Christian Robert <christian.rob...@polymtl.ca>:
> well, no, > > I'm perfectly ok with the fact that gnuapl do not compile on old redhat 4, > or on old redhat 5 > with very *old* compilers. > > please Upgrade. > > my 2 cents, > > Xtian. > > > > On 2017-03-10 02:09, Alexey Veretennikov wrote: > >> Hi Juergen, >> >> Here is the patch which introduces the new configure option: >> --disable-werror >> If this option is set then the -Werror flag is not added to compiler >> options. >> By default it is like it is now - -Werror is present. >> >> With this option I was able to turn off compiler warnings. >> >> I ran autoreconf on my machine but it produces more diffs, which I don't >> want to attach. I believe it is better to you to run it on your machine >> and submit to svn instead of me providing them as a patch. >> >> >> >> >> >> Juergen Sauermann <juergen.sauerm...@t-online.de> writes: >> >> Hi Alexey, >>> >>> I believe it is not good if we have to introduce additional code just to >>> suppress warnings. >>> In particular if the warning is obviously bogus. >>> >>> -Werror is on purpose in order to improve the code quality of GNU APL. >>> If we would turn it off then that goal would be undermined. >>> >>> I suppose that you can run configure like this: >>> >>> CXXFLAGS="-Wnoerror" ./configure >>> >>> If that doesn't work then configure.ac line 39 is place to change the >>> CXXFLAGS. >>> After that autoreconf and a new ./configure is needed for the change to >>> have an effect. >>> >>> /// Jürgen >>> >>> On 03/09/2017 11:29 AM, Alexey Veretennikov wrote: >>> >>> Hi, >>> >>> I'm trying to compile GNU APL with GCC 3.4.6 armv5. There are couple of >>> bogus compiler warnings, >>> mainly about variable might be uninitialized. >>> Sometimes the situations are like this: >>> >>> SomeObject * ptr = new SomeObject(arg); >>> >>> - here compiler complains (sometimes) what ptr might be used >>> uninitialized. >>> I've fixed it by separating variable declaration and initialization >>> with the real value, like this: >>> In the beginning of the function: >>> >>> SomeObject * ptr = 0; >>> >>> .... >>> ptr = new SomeObject(); >>> >>> So I can fix them by rearranging a code a little. It doesn't hurt as it >>> seems. >>> But maybe it is not way to go, to complicate the code to satisfy the >>> ancient compiler? >>> >>> There are other issues, mainly related to HEX macro, where we supply >>> pointer to this macro. >>> On 32bits machine the conversion int64_t(const char*) produces the >>> warning. >>> I could solve them by introducing >>> HEX(reinterpret_cast<int64_t>(ptr)) >>> >>> It makes code compile without warnings but looks not that pleasant. >>> >>> But maybe there is a possibility to turn off -Werror with the >>> ./configure option? >>> >>> Br, >>> /Alexey >>> >>> >>> >> >
