OSX catalina GCC macports

[ambitslix]

Having this issue:

export CC=/opt/local/bin/gcc-mp-9; export CXX=/opt/local/bin/g++-mp-9

boost is in /opt/local

I added this to CMakeKists.txt

elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra") include_directories("/opt/local/include") link_directories("/opt/local/lib") add_definitions( -DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_CHRONO_HEADER_ONLY -DYAS_SERIALIZE_BOOST_TYPES -DYAS_OBJECT_MAX_MEMBERS=50 )

-- The C compiler identification is GNU 9.2.0
-- The CXX compiler identification is GNU 9.2.0
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Check for working C compiler: /opt/local/bin/gcc-mp-9
-- Check for working C compiler: /opt/local/bin/gcc-mp-9 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag - yes
-- Check for working CXX compiler: /opt/local/bin/g++-mp-9
-- Check for working CXX compiler: /opt/local/bin/g++-mp-9 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done

[niXman]

still, what compiler do you use? because in the subject I can see AppleClang but in the body export CXX=/opt/local/bin/g++-mp-9 and -- The CXX compiler identification is GNU 9.2.0

[niXman]

I can't confirm this issue using gcc-9.2.1 on linux.

[niXman]

also, please compile and execute this code using the same compiler:

#include <iostream>

template<typename ...Types>
void foo(Types ...) { std::cout << __PRETTY_FUNCTION__ << std::endl; }

int main() {
    foo(std::int64_t{}, std::uint64_t{}, std::size_t{});
}

and show me the output.

[ambitslix]

Clang compiles fine the test code:

$ g++ -std=c++11 test.cpp -o test

but with gcc:

export CC=/opt/local/bin/gcc-mp-9;export CXX=/opt/local/bin/g++-mp-9

$$CXX -std=c++11 test.cpp -o test In file included from /opt/local/include/gcc9/c++/bits/postypes.h:40, from /opt/local/include/gcc9/c++/iosfwd:40, from /opt/local/include/gcc9/c++/ios:38, from /opt/local/include/gcc9/c++/ostream:38, from /opt/local/include/gcc9/c++/iostream:39, from test.cpp:1: /opt/local/include/gcc9/c++/cwchar:44:10: fatal error: wchar.h: No such file or directory 44 | #include | ^~~~~ compilation terminated.

Looks like this problem: https://stackoverflow.com/questions/52509602/cant-compile-c-program-on-a-mac-after-upgrade-to-mojave ...

I tried both, first the clang but it errors out earlier, so I switched to gcc.

-- The C compiler identification is AppleClang 11.0.0.11000033
-- The CXX compiler identification is AppleClang 11.0.0.11000033
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: 

[niXman]

in the topic you write about one error, but now you write about another...

how many members in the YAS_OBJECT() in the last paste?

[niXman]

wchar.h: No such file or directory - I think this error is due to the fact that some package is not installed...

[niXman]

error: no matching function for call to 'tuple_switch' - I think you forgot to specify YAS_OBJECT_MAX_MEMBERS: https://github.com/niXman/yas/blob/master/tests/base/CMakeLists.txt#L14

[ambitslix]

I have this:

if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang")
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra")
    add_definitions(
        -DBOOST_ERROR_CODE_HEADER_ONLY
        -DBOOST_CHRONO_HEADER_ONLY
        -DYAS_SERIALIZE_BOOST_TYPES
        -DYAS_OBJECT_MAX_MEMBERS=50
    )
elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra")
    add_definitions(
        -DBOOST_ERROR_CODE_HEADER_ONLY
        -DBOOST_CHRONO_HEADER_ONLY
        -DYAS_SERIALIZE_BOOST_TYPES
        -DYAS_OBJECT_MAX_MEMBERS=50
    )
        include_directories("/opt/local/include")
        link_directories("/opt/local/lib")

elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "MSVC")
    if(CMAKE_SIZEOF_VOID_P EQUAL 8)
        set(COMPILER_BITS 64)
    else()
        set(COMPILER_BITS 32)
    endif()

...

I've resolved the issue with missing wchar.h so the test program compiles fine under both gcc and clang.

[niXman]

please attach this output as file, not as copy-paste

[niXman]

there are two different errors for different compilers. will try to solve the error that occurs when using GCC.

please compile, execute and show me the output for this code:

#include <iostream>

template<typename ...Types>
void foo(Types ...) { std::cout << __PRETTY_FUNCTION__ << std::endl; }

int main() {
    foo(std::int64_t{}, std::uint64_t{}, std::size_t{});
}

[ambitslix]

$ g++ -std=c++11 test.cpp -o test
$ ./test
void foo(Types...) [Types = <long long, unsigned long long, unsigned long>]
$ echo $CXX

$ export CC=/opt/local/bin/gcc-mp-9;export CXX=/opt/local/bin/g++-mp-9
$ $CXX -std=c++11 test.cpp -o test
$ ./test
void foo(Types ...) [with Types = {long long int, long long unsigned int, long unsigned int}]
att

[niXman]

please change this line to const std::uint64_t b64size = modp_b64_encode(ar, buf.data, buf.size); and let me know about the result.

[ambitslix]

yas-gcc.log

[niXman]

and this line the same way please.

[ambitslix]

yas-gcc.log

[niXman]

also please change this and this lines to void write(const T &v, __YAS_ENABLE_IF_IS_ANY_OF(T, std::uint16_t, std::uint32_t, std::uint64_t, long unsigned int)) {

i.e. just add the long unsigned int to the list of types

[ambitslix]

yas-gcc.log

[niXman]

also please change this and this lines to void read(T &v, __YAS_ENABLE_IF_IS_ANY_OF(T, std::uint16_t, std::uint32_t, std::uint64_t, long unsigned int)) {

[ambitslix]

yas-gcc.log

[niXman]

please replace long unsigend int as long unsigned int =)

[ambitslix]

With that it builds now with gcc. With clang I attached the log if you're interested.

[niXman]

please add the -save-temps option to the CMAKE_CXX_FLAGS here, run build and provide me main.ii file.

[ambitslix]

There is no main.ii, here is the log. yas-clang.log

[niXman]

There is no main.ii

it should be in the cmake's build directory

[ambitslix]

The issue began here:

CMAKE_CXX_COMPILER_ID="AppleClang"

So I changed to:

if(CMAKE_CXX_COMPILER_ID MATCHES "(C|c?)lang")

main.ii.zip

[ambitslix]

Are you going to merge these changes if I create a pull request or was this just a temporary patch?

[niXman]

I planned to make this commit myself, but I was stuck on refactoring to add new functionality...

[ambitslix]

Hello this is a followup to this issue. Currently with macports/GCC:

gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.21)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

gcc-mp-9 --version
gcc-mp-9 (MacPorts gcc9 9.4.0_0) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Please Note I'm reporting the issue with using GCC not Clang. The above log is just to show what compilers are installed.

The following code fails when using std::size_t but compiles with std::uint64_t:

    std::vector<uint8_t>                       buf(1024);
    constexpr std::size_t                      opts = yas::json | yas::no_header;
    yas::mem_ostream                           os(buf.data(), buf.size());
    yas::json_oarchive<yas::mem_ostream, opts> oa(os);

    std::size_t x = 1; // <============================== FAILS
//    std::uint64_t x = 1; <============================ OK

    oa& YAS_OBJECT_NVP("Foo", ("size_t", yas::init(x)));

See error log below

log.txt

[niXman]

hi,

I think std::is_same<std::size_t, std::uint64_t>::value will be false?

please look at this restriction: https://github.com/niXman/yas/blob/master/include/yas/detail/io/json_streams.hpp#L112

so I think that is correct.

[ambitslix]

I see, if that's the case I'm OK with that and I agree that they(size_t and uint64_t) should be different. Does that mean that yas doesn't support size_t JSON serialization? My solution currently is to simply not use size_t...

[niXman]

since size_t can be 32-bit or 64-bit, support for this type was deliberately limited. but yes, size_t support could be enabled for json and text archives. but in this case, the same yas::object would be supported by json/text archives but it would cause a compilation error when using with binary archive, and I think this would cancel out the meaning of size_t support for json/text archives.