Building a program with bazel on mingw, I get this error:
external/com_github_protocolbuffers_protobuf/src/google/protobuf/port_undef.inc:122:28: error: expected ')' at end of input
122 | #pragma GCC diagnostic pop
| ^
| )
external/com_github_protocolbuffers_protobuf/src/google/protobuf/stubs/port.h:266:10: note: to match this '('
266 | return (((x & uint64_t{0xFFu)) << 56) |
That quoted line 266 is clearly completely wrong, which makes it easy to search for; it was fixed in the protobuf code in this bug, which was closed in May 2021 and probably released in 3.17.1.
This is coming from a version of protobuf that bazel has downloaded, presumably because it can't find the system protobuf library. So... why is it trying to use this old version of the library, and is there any way to make it stop?
Related
I am trying to setup my development toolchain for AVR in Debian Linux, from source donwloaded directly from gnu.org, latest versions.
I am stocked in this step:
#./configure --target-avr --program-prefix='avr-'
# make
Configure terminates well building my Makefile. However, make gives me a lot of compilation errors similar to this:
----------------------------------------------------------------------------------------
In file included from ./fopen_unlocked.c:76:
/usr/include/stdio_ext.h:46:15: error: old-style parameter declarations in prototyped function definition
46 | extern size_t __fbufsize (FILE *__fp) __THROW;
| ^~~~~~~~~~
./fopen_unlocked.c:129: error: expected ‘{’ at end of input
129 | }
|
./fopen_unlocked.c:129: warning: control reaches end of non-void function [-Wreturn-type]
129 | }
------------------------------------------------------------------------------------
It is unthinkable that those source files are wrong, so obviously I am missing something. Any help on this will be appreciated.
as: unrecognized option '-mmcu=avr2', which make me think that gcc is invoking the wrong assembler.
Yes. Reason might be that avr-gcc was not configured / built correctly. On some Linux systems there are packages for GNU tools for AVR named binutils-avr, gcc-avr and avr-libc.
Maybe you missed to install the Binutils part? ... no idea why they are using separate packages, they only make sense together.
Anyway, you might also read avr-gcc 8.1.0 uses as instead of avr-as.
I have a compilation error on macOS v11 (Big Sur) with the standard Clang compiler (version 13.0.0).
I am trying to include the sys/sysmacros.h to use the makedev() function which surprisingly is mentioned on the Apple developer website and should be compatible with macOS 15.5+.
Including sys/types.h also gives me an error, however sys/stat.h works. Sadly it still doesn't give me the makedev(), major() and minor() functions that I need.
The Linux manual page of makedev states there were some changes in the glibc library, but as far as I know, macOS does not use the glibc library.
There should be a simple way of installing glibc on macOS using Homebrew (brew) as described here, but I get the same error as was mentioned in this question. So apparently currently there is no proper way of doing it and then I am not sure if this will solve my problem.
Is there a solution to this?
The macro makedev is defined in sys/types.h. Just add #include <sys/types.h> into your files. sys/types.h is a header file of Kernel.framework. You should set it in the Clang invocation, like clang -framework Kernel ....
You can also define these macros as they are defined in sys/types.h:
#define major(x) ((int32_t)(((u_int32_t)(x) >> 24) & 0xff))
#define minor(x) ((int32_t)((x) & 0xffffff))
#define makedev(x, y) ((dev_t)(((x) << 24) | (y)))
I am attempting to build LightGBM version 2.2.4 (git hash 5256cda69300d6b83b18180da2992a1e50a6b392) on an IBM Power9 system ("Witherspoon", CPU is a Power System AC922, 8335-GTH) running Red Hat Enterprise Server 7.5 (Maipo).
I am using the RHEL-packaged C compiler, gcc 4.8.5, a local version of cmake, version 3.13.1, and a local installation of Boost version 1.64.0, The system has CUDA 9.2 installed, and I have located the libOpenCL directories and include files.
My configuration operation is (from inside a newly-created build directory in the root of the unpacked LightGBM tree):
# export BOOST_ROOT=/share/sw/boost/1_64_0/
# cmake3 -DUSE_GPU=1 -DOpenCL_LIBRARY=/usr/lib64/nvidia/libOpenCL.so -DOpenCL_INCLUDE_DIR=/usr/include/CL/ ..
# make
The configuration step apparently succeeds, generating a runnable makefile.
The build fails at around 41% with errors from deep in the bowels of Boost:
[ 41%] Building CXX object CMakeFiles/_lightgbm.dir/src/treelearner/data_parallel_tree_learner.cpp.o
In file included from /share/sw/boost/1_64_0/include/boost/mpl/aux_/integral_wrapper.hpp:22:0,
from /share/sw/boost/1_64_0/include/boost/mpl/int.hpp:20,
from /share/sw/boost/1_64_0/include/boost/mpl/lambda_fwd.hpp:23,
from /share/sw/boost/1_64_0/include/boost/mpl/aux_/na_spec.hpp:18,
from /share/sw/boost/1_64_0/include/boost/mpl/identity.hpp:17,
from /share/sw/boost/1_64_0/include/boost/iterator/detail/enable_if.hpp:11,
from /share/sw/boost/1_64_0/include/boost/iterator/transform_iterator.hpp:11,
from /share/sw/boost/1_64_0/include/boost/algorithm/string/iter_find.hpp:17,
from /share/sw/boost/1_64_0/include/boost/algorithm/string/split.hpp:16,
from /wrk/user/src/lightgbm/LightGBM/compute/include/boost/compute/device.hpp:18,
from /wrk/user/src/lightgbm/LightGBM/compute/include/boost/compute/context.hpp:19,
from /wrk/user/src/lightgbm/LightGBM/compute/include/boost/compute/buffer.hpp:15,
from /wrk/user/src/lightgbm/LightGBM/compute/include/boost/compute/core.hpp:18,
from /wrk/user/src/lightgbm/LightGBM/src/treelearner/gpu_tree_learner.h:27,
from /wrk/user/src/lightgbm/LightGBM/src/treelearner/parallel_tree_learner.h:5,
from /wrk/user/src/lightgbm/LightGBM/src/treelearner/data_parallel_tree_learner.cpp:1:
/share/sw/boost/1_64_0/include/boost/mpl/vector.hpp:28:18: error: pasting ")" and "20" does not give a valid preprocessing token
BOOST_PP_CAT(vector, BOOST_MPL_LIMIT_VECTOR_SIZE).hpp \
^
/share/sw/boost/1_64_0/include/boost/preprocessor/cat.hpp:29:34: note: in definition of macro ‘BOOST_PP_CAT_I’
# define BOOST_PP_CAT_I(a, b) a ## b
^
/share/sw/boost/1_64_0/include/boost/mpl/vector.hpp:28:5: note: in expansion of macro ‘BOOST_PP_CAT’
BOOST_PP_CAT(vector, BOOST_MPL_LIMIT_VECTOR_SIZE).hpp \
^
/share/sw/boost/1_64_0/include/boost/mpl/vector.hpp:36:49: note: in expansion of macro ‘AUX778076_VECTOR_HEADER’
# include BOOST_PP_STRINGIZE(boost/mpl/vector/AUX778076_VECTOR_HEADER)
^
In file included from /share/sw/boost/1_64_0/include/boost/math/policies/policy.hpp:14:0,
from /share/sw/boost/1_64_0/include/boost/math/special_functions/math_fwd.hpp:28,
from /share/sw/boost/1_64_0/include/boost/math/special_functions/sign.hpp:17,
from /share/sw/boost/1_64_0/include/boost/lexical_cast/detail/inf_nan.hpp:34,
from /share/sw/boost/1_64_0/include/boost/lexical_cast/detail/converter_lexical_streams.hpp:63,
from /share/sw/boost/1_64_0/include/boost/lexical_cast/detail/converter_lexical.hpp:54,
from /share/sw/boost/1_64_0/include/boost/lexical_cast/try_lexical_convert.hpp:42,
from /share/sw/boost/1_64_0/include/boost/lexical_cast.hpp:32,
from /wrk/user/src/lightgbm/LightGBM/compute/include/boost/compute/detail/meta_kernel.hpp:23,
from /wrk/user/src/lightgbm/LightGBM/compute/include/boost/compute/iterator/buffer_iterator.hpp:26,
from /wrk/user/src/lightgbm/LightGBM/compute/include/boost/compute/algorithm/detail/copy_on_device.hpp:18,
from /wrk/user/src/lightgbm/LightGBM/compute/include/boost/compute/algorithm/copy.hpp:26,
from /wrk/user/src/lightgbm/LightGBM/compute/include/boost/compute/container/vector.hpp:32,
from /wrk/user/src/lightgbm/LightGBM/src/treelearner/gpu_tree_learner.h:28,
from /wrk/user/src/lightgbm/LightGBM/src/treelearner/parallel_tree_learner.h:5,
from /wrk/user/src/lightgbm/LightGBM/src/treelearner/data_parallel_tree_learner.cpp:1:
/share/sw/boost/1_64_0/include/boost/mpl/vector.hpp:36:73: fatal error: boost/mpl/__attribute__((altivec(vector__)))/__attribute__((altivec(vector__)))20.hpp: No such file or directory
# include BOOST_PP_STRINGIZE(boost/mpl/vector/AUX778076_VECTOR_HEADER)
From the messages, it looks like some preprocessor string manipulation has gone wrong, it's maybe trying to find the "vector20.hpp" file in the boot/mpl/vector include directory, but the BOOST_PP_CAT operation has gone wrong, so it's failing to construct a proper filename? Also, the "altivec" is implicated, the Power9 CPU is altivec-capable, maybe an additional header or compiler switch is required?
I can successfully build (with warnings) on a Debian 9 "stretch" system with x86_64 architecture and CUDA 9.1 (for the libOpenCL stuff), with the Debian-packaged Boost version 1.62.
I also tried building the Power9 version against Boost 1.69, and against Boost 1.62 (the one that worked on Debian), and got the same errors in the same place.
Help?
This is addressed in an issue on the LightGBM github, which I somehow missed on my initial search.
This build attempt is misguided.
The compilation problem is apparently an altivec/boost interaction, and there's no OpenCL GPU support on the Power architecture, and LightGBM is OpenCL under the hood, so the effort is doomed in any case.
I am trying to to compile wxWidgets 3.0.2 found here.
I need this library, so that I can compile SimSpark.
I have tried installing the library via MacPorts - this does work. But when I try to compile SimSpark, the compiler states the following:
In file included from /opt/local/include/gcc49/c++/type_traits:35:0,
from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/strvararg.h:25,
from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/string.h:46,
from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/memory.h:15,
from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/object.h:19,
from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/event.h:16,
from /Users/YEED/Downloads/simspark-0.2.4/plugin/inputwx/inputwx.cpp:23:
/opt/local/include/gcc49/c++/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
I believe that I need to compile wxWidgets with C++11 support, since I already included the C++11 relevant flags when making SimSpark.
When I try to compile wxWidgets, I get a bunch of compiler errors that refer to the same .h file - which is part of CoreFoundation:
In file included from /usr/include/Availability.h:184:0,
from /usr/include/stdlib.h:61,
from /usr/include/assert.h:44,
from ../include/wx/debug.h:13,
from ../include/wx/defs.h:743,
from ../include/wx/wxprec.h:12,
from ../src/common/filefn.cpp:20:
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFDateFormatter.h:53:34: error: expected '}' before '__attribute__'
kCFISO8601DateFormatWithYear API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0)) = (1UL << 0),
When you look into that specific file, there are a bunch of lines that miss a closing ) and resemble the one printed by the compiler as well. (There should be a closing ) before the comma at the end of the line, right?)
So my question is, is this an actual error in CoreFoundation? If so, how can I fix this or work around it? Or am I actually completely misunderstanding the compiler error thrown when compiling SimSpark in the first place?
EDIT:
I couldn't get wxWidgets to compile, but I have fixed my issues compiling SimSpark with the MacPorts version of wxWidgets. The problem lay within using different compilers (gcc and clang) for the two.
And no wonder as there is no such file in ...\boost_1_58_0\stage\lib. How can I get one ? I only have:
boost_1_58_0\stage\lib\libboost_filesystem-vc120-mt-s-1_58.lib
boost_1_58_0\stage\lib\libboost_filesystem-vc120-s-1_58.lib
in there. Tried to compile boost with various options ending up with tacking --build-type=complete to it (the "poor man's" solution from Linker error LNK1104 with 'libboost_filesystem-vc100-mt-s-1_49.lib') to get:
> b2 toolset=msvc threadapi=win32 link=static runtime-link=static \
variant=release address-model=32 --with-filesystem --with-locale --with-regex \
--with-system --with-iostreams --build-type=complete
the command line being suggested in the readme of the project that I am importing - still no joy. It is a CMake project I got into some pains to build an MSVS solution for.
NB: my problem was solved when looking carefully at the CMake gui:
I realized that it is the Debug configuration that did not build and sure enough when I right clicked on the "solution" > Configuration Manager > changed to a release build all was ok. Still the question remains - how do I get those libboost_filesystem-vc120-mt-sgd-1_58.lib builds ?
You'd need to have runtime-link=static runtime-debugging=on variant=debug in the b2 command line args to get sgd.
From the boost docs about library naming on Windows (specifically the ABI tag portion):
ABI tag: encodes details that affect the library's interoperability with other compiled code. For each such feature, a single letter is added to the tag:
Key | Use this library when: | Boost.Build option
=====================================================================================
s | linking statically to the C++ standard library and | runtime-link=static
| compiler runtime support libraries. |
-------------------------------------------------------------------------------------
g | using debug versions of the standard and runtime | runtime-debugging=on
| support libraries. |
-------------------------------------------------------------------------------------
y | using a special debug build of Python. | python-debugging=on
-------------------------------------------------------------------------------------
d | building a debug version of your code. | variant=debug
-------------------------------------------------------------------------------------
p | using the STLPort standard library rather than the | stdlib=stlport
| default one supplied with your compiler. |