Yeah, I have no idea what the compiler is objecting to. There's nothing
wrong with that bit of code.
Rick
On Mon, Feb 18, 2019 at 5:18 PM Enrico Sorichetti via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:
> Unfortunately it seems there are some issues with the centos 7 gcc
>
More CentOS7 and SLES12 slave build failures further down the build:
In file included from interpreter/platform/unix/SysRexxUtil.cpp:181:0:
interpreter/runtime/RexxUtilCommon.hpp: In constructor
‘TreeFinder::AttributeMask::AttributeMask()’:
interpreter/runtime/RexxUtilCommon.hpp:278:11: error:
Unfortunately it seems there are some issues with the centos 7 gcc compilers
they are a bit outdated g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
And the build chokes with
In file included from
/home/vagrant/ooRexx.svn.src/interpreter/platform/unix/SysRexxUtil.cpp:181:0:
more of the [ ] operator issues coming up:
..\interpreter\platform\windows\SysRexxUtil.cpp(880): error C2666:
'FileNameBuffer::operator []': 3 overloads have similar conversions
..\interpreter\memory\FileNameBuffer.hpp(205): note: could be 'char
::operator [](size_t)'
There are spurious leading "_" characters on the #ifdef test. I'll fix this
with the other issues you raised shortly.
Rick
On Mon, Feb 18, 2019 at 3:53 PM Erich Steinböck
wrote:
> Our Mac build slave finds _PC_CASE_SENSITIVE
>
> ~~~
> -- Looking for _PC_CASE_SENSITIVE
> -- Looking for
Here is the tested and WORKING code sequence
IIRC I had to fix the testSuite in a couple of places
I did run the test suite twice ,
once on the boot volume ( case insensitive by default )
The second time on an external disk with a case sensitive file system
Pathconf needs the file or
Our Mac build slave finds _PC_CASE_SENSITIVE
~~~
-- Looking for _PC_CASE_SENSITIVE
-- Looking for _PC_CASE_SENSITIVE - found
~~~
but still correctly builds SysFileSystem which seems impossible due to a
typo `if (res \= -1)` that should prevent compilation. (The bug repeats a
few lines further
Our CentOS7 and SLES12 salve builds fail with
[ 11%] Building CXX object
CMakeFiles/rexx.dir/interpreter/classes/ArrayClass.cpp.o
In file included from /usr/include/c++/4.8.2/bits/stl_algo.h:66:0,
from /usr/include/c++/4.8.2/algorithm:62,
from
The 32-bit build (VS 2017 15.9.3) on our Windows slave stops with two
warnings and then a terminating error:
..\interpreter\parser\ProgramSource.cpp(753): warning C4244: 'argument':
conversion from 'int64_t' to 'size_t', possible loss of data
..\interpreter\parser\ProgramSource.cpp(758): warning
Tested on 64-bit ooRexx as well and works like a charm, kudos to Enrico!
---
So a little roundup:
* Enrico's CMake sample works on Windows as well, tested with both the 32 and
64 bit Microsoft
compiler!!
* Windows specifics:
o the ooRexx installation copies the *.h and *.lib
On 18.02.2019 17:22, Enrico Sorichetti via Oorexx-devel wrote:
> Dear Rony
> I am very happy that it was useful
>
> Looking at the status of variable for complex cmakelists
> ( and I wrote a couple of them )
> Is usually the only way to debug cmakelists errors
>
> The vdump module was the
On 18.02.2019 17:10, Rony G. Flatscher wrote:
> A remark: forgot to delete the lines:
> cl : Command line warning D9002 : ignoring unknown option '-g'
>
> Those warnings were issued, because I used "cmake -G ...", removing the "-G"
> (from a very, very,
> very old note) removed the warning in my
Dear Rony
I am very happy that it was useful
Looking at the status of variable for complex cmakelists
( and I wrote a couple of them )
Is usually the only way to debug cmakelists errors
The vdump module was the first one I wrote a long time ago
To get a better knowledge of the cmake ways
A remark: forgot to delete the lines:
cl : Command line warning D9002 : ignoring unknown option '-g'
Those warnings were issued, because I used "cmake -G ...", removing the "-G"
(from a very, very,
very old note) removed the warning in my second runs. So please ignore them in
my previous
Tried it on Windows:
G:\oorexx.tmp\enrico\win32>call "e:\Programme\Microsoft Visual Studio
14.0\VC\vcvarsall.bat" x86
-- The C compiler identification is MSVC 19.0.24215.1
-- The CXX compiler identification is MSVC 19.0.24215.1
-- Check for working C compiler:
Thank You Rick
But I guess that there was a leftover from Your tests
At line 74 the
#undef HAVE_FNM_CASEFOLD
Should not be there
Tested … it works in both cases !
E
> On 18 Feb 2019, at 09:45, Enrico Sorichetti wrote:
>
> Unfortunately ...
> whenever a new define is introduced in config.h
Cmake has a module GNUInstallDirs
Which tries to determine according to the GNU standards
the low lever directory for the components according to the GNU standards
( whether or not You like the GNU thing )
From my experiments seems that the only dirs define by the GNU standards are
lib and
Unfortunately ...
whenever a new define is introduced in config.h
It is my habit to check that things continue to work even if the same is
undeffed
That is the case for HAVE_FNM_CASEFOLD
Without it the build fails …
- 1) if fnmatch.h(*) and FNM_CASEFOLD are not available the thing should
18 matches
Mail list logo
