Unable to recognize the global variables set in Ubuntu - makefile

I have been following the steps mentioned here Google Weave-Libiota on Ubuntu. It's been successful until running test step. Later on, we need to write a header file defining the api_keys, Client_secret key and client_id and set its path to a Global Environment variable so that the program main.c uses API KEY file through header files and Global variable. But it's not recognizing.
Errors to the command make -C /host/examples/light image:
wozartubuntu#wozartubuntu-iMac:~$ cd libiota/
wozartubuntu#wozartubuntu-iMac:~/libiota$ sudo make -C examples/host/light/
[sudo] password for wozartubuntu:
make: Entering directory '/home/wozartubuntu/libiota/examples/host/light'
gcc -Wall -Werror -Os -fno-builtin -ffunction-sections -fdata-sections -fstack-usage -DIOTA_BUILD_TIME=1485236028 -DSUPPORTS_FLOATING_POINT_FORMAT -I/usr/local/include -std=gnu99 -MMD -I$IOTA_ROOT -I$IOTA_ROOT/include -DJSMN_PARENT_LINKS -DJSMN_SHORT_TOKENS -I$IOTA_ROOT/third_party/jsmn -c -o /home/wozartubuntu/libiota/out/host/examples/light/main.o /home/wozartubuntu/libiota/examples/host/light/main.c
In file included from /home/wozartubuntu/libiota/examples/host/light/main.c:22:0:
/home/wozartubuntu/libiota/include/iota/oauth_keys.h:23:38: fatal error: IOTA_OAUTH2_KEYS_HEADER.h: No such file or directory
compilation terminated.
../../../examples/host/common.mk:33: recipe for target '/home/wozartubuntu/libiota/out/host/examples/light/main.o' failed
make: *** [/home/wozartubuntu/libiota/out/host/examples/light/main.o] Error 1
make: Leaving directory '/home/wozartubuntu/libiota/examples/host/light'
wozartubuntu#wozartubuntu-iMac:~/libiota$
Program causing the error:
/*
* Copyright 2016 Google Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#ifndef LIBIOTA_INCLUDE_IOTA_OAUTH_KEYS_H_
#define LIBIOTA_INCLUDE_IOTA_OAUTH_KEYS_H_
#include "IOTA_OAUTH2_KEYS_HEADER"
#endif // LIBIOTA_INCLUDE_IOTA_OAUTH_KEYS_H_
How to resolve these errors?

Related

CPU2017 benchmark 510.parest_r build failed with gcc9.3 and gcc9.4

everyone.
I'm try to build CPU2017 intrate and fprate test set on aarch64 server with gcc9.3. All the benchmark build successed, except 510.parest_r. Then i try build it with gcc9.4, meet the same error. I used the Example-gcc-linux-aarch64.cfg as configure file, just edit the gcc path.
Here is the failed info:
/home/gcc9.3/bin/g++ -std=c++03 -mabi=lp64 -c -o source/me-tomography/synthetic_data.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -O3 -DSPEC_LP64 source/me-tomography/synthetic_data.cc
/home/gcc9.3/bin/g++ -std=c++03 -mabi=lp64 -c -o source/multigrid/mg_base.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -O3 -DSPEC_LP64 source/multigrid/mg_base.cc
/home/gcc9.3/bin/g++ -std=c++03 -mabi=lp64 -c -o source/me-tomography/measurements.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -O3 -DSPEC_LP64 source/me-tomography/measurements.cc
init2.c:52: MPFR assertion failed: p >= 2 && p <= ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
during GIMPLE pass: forwprop
source/me-tomography/measurements.cc: In constructor 'METomography::Measurements::ReferencedMeasurements::RatioMinusRatio<dim, number>::RatioMinusRatio(const libparest::Slave::Stationary::ProblemDescription&, const dealii::Function<dim>&, const std::set<unsigned char>&) [with int dim = 3; number = double]':
source/me-tomography/measurements.cc:1739:7: internal compiler error: Aborted
1739 | RatioMinusRatio<dim,number>::
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
0xafbd97 crash_signal
../.././gcc/toplev.c:326
0xffff9e304d78 __GI_raise
../sysdeps/unix/sysv/linux/raise.c:51
0xffff9e2f1aab __GI_abort
/build/glibc-RIFKjK/glibc-2.31/stdlib/abort.c:79
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
specmake: *** [/home/spec/cpu2017_aarch64/benchspec/Makefile.defaults:356: source/me-tomography/measurements.o] Error 1
specmake: *** Waiting for unfinished jobs....
The failed info seem be caused by the MPRF float percision setting?
I tried build 510.parest_r with llvm-10, build success.
By the way, i build same gcc9.3 in x86_64 server, build 510.parest_r success.
You've found a bug in an older version of GCC (or possibly your system's RAM is failing, but unlikely if it consistently crashes at the same place). Or perhaps a bug in MPFR, although that seems less likely.
If you preprocess that source (add -E or -save-temps to the command line that crashed) and put it on https://godbolt.org/, does it still crash the same way with current ARM64 GCC, e.g. a nightly build of trunk? (https://godbolt.org/z/K6GnrYrj1 is ARM64 GCC trunk, with your command line args without the preprocessor stuff, which won't matter when compiling CPP output.)
If it still crashes with current GCC, then file a bug report on https://gcc.gnu.org/bugzilla/, ideally with a MCVE of the part of the source that triggers the bug. (Remove as many parts of the file as you can while preserving the crash behaviour. e.g. take out tons of stuff, undo if that makes it compile.)
If it doesn't crash with newer GCC, it might already be a known bug, or got fixed by accident, or a different MPFR or other library version mattered. In that case, maybe not worth reporting it upstream. Or if you do make sure to include the fact that the range of affected versions doesn't include GCC12 or current trunk. Probably this Stack Overflow Q&A is sufficient for future users to know that it's a known bug.

Compiling OpenFOAM's scotch on macOS

I am trying to compile the scotch library embedded into the OpenFOAM.org third-party repository here. I ran the command
make -C ./ThirdParty-dev/scotch_6.0.9/src/
and I get the below error message:
(cd libscotch ; make VERSION=6 RELEASE=0 PATCHLEVEL=9 scotch && make install)
make \
CC="gcc" \
CCD="gcc" \
scotch.h \
scotchf.h \
libscotch.so \
libscotcherr.so \
libscotcherrexit.so
gcc -O3 -DCOMMON_FILE_COMPRESS_GZ -DCOMMON_RANDOM_FIXED_SEED -DSCOTCH_RENAME -Drestrict=__restrict -DSCOTCH_VERSION_NUM=6 -DSCOTCH_RELEASE_NUM=0 -DSCOTCH_PATCHLEVEL_NUM=9 dummysizes.c -o dummysizes -Xlinker --no-as-needed -lz -lm -lrt
ld: unknown option: --no-as-needed
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [dummysizes] Error 1
make[1]: *** [scotch] Error 2
make: *** [libscotch] Error 2
I am not sure what this error message means. If it is complaining about scotch not being available, that's why I'm compiling it in the first place. Out of desperation, I also tried to install it via brew install scotch to no avail. I would appreciate it if you could help me understand the above error message and resolve the issue.
The scotch build is a bit different in that they manage all of the OS/compiler-specific bits separately via a src/Makefile.inc that the user is responsible for providing. Of course they also provide a number of examples in the src/Make.inc/ directory, but they may not properly cover your particular OS/compiler requirements.
Since you grabbed the scotch source files from a third-party source instead of from the pristine upstream sources, you also have someone else's src/Makefile.inc that happens to be a Linux-specific version. So no surprise that it has incorrect link (or even compile) options.
The Darwin-specific makefile adjustments that are used by openfoam.com:
# Linux:
LIB = .so
ARFLAGS = $(WM_CFLAGS) -shared -o
LDFLAGS = -Xlinker --no-as-needed $(WM_LDFLAGS) -lm -lrt
# Darwin:
LIB = .dylib
ARFLAGS = $(WM_CFLAGS) -dynamiclib -undefined dynamic_lookup -o
LDFLAGS = $(WM_LDFLAGS) -lm
Without worrying about any other source of differences (in the OpenFOAM WM_CFLAGS and WM_LDFLAGS variables), it would appear that you are using Linux (gcc only?) link options for Darwin - so should be no surprise that they don't work.
The location for the pristine scotch sources move around a bit (seems to be related to their filer) but a reasonably uptodate reference is always included in the OpenFOAM ThirdParty BUILD.md. The URLs are provided as links, but also listed near the bottom of the file for easy grepping.
The current scotch link : https://gforge.inria.fr/frs/download.php/file/38352/scotch_6.1.0.tar.gz
The newest scotch is actually scotch-6.1.2 but there appears to be a regression in the dgraph calculation (the distributed graph in ptscotch) so probably better to stick with 6.1.0 for now.
Here is the information for the scotch repo itself (https://gitlab.inria.fr/scotch/scotch) - should be the most reliable source of information.

gcc failed with exit status 1 (limits.h doesn't exist error) while installing textract Python3 macOs

I am trying to use textract on Python3 on MacOS.
`pip install textract`
fails with error as following:
#include_next <limits.h> /* recurse down to the real one */
^
compilation terminated.
error: command 'gcc' failed with exit status 1
which gcc
/usr/local/bin/gcc
gcc --version
gcc (Homebrew GCC 4.9.4_1) 4.9.4
Copyright (C) 2015 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.
I tried to use default gcc compiler after updating through xcode v4.2.0 /usr/bin/gcc but it failed with very similar error: gcc failed with status 1: al.h not found
I've also tried installing gcc from anaconda but that failed with the same error limits.h doesn't exist.
Appreciate your help!
P.S. my ultimate goal is to extract text from Pdf. I tried with PdfMiner.six and PyPdf2 but both of these fail to properly handle spaces. They either remove all whitespaces, concatenating all words or add strange whitespaces.

gcc options case sensitivity, passing `-on` instead of `-On`

I just came across this answer GCC Compiler Optimizations, can't link with a main executable file '_' for architecture x86_64 and it made me wonder, is gcc really case sensitive and if yes, what is -on actually? I always used -On to indicate the level of optimization desired. -on does not make any sense to me. However, I tried a little program with -o3 and gcc swallowed it happily. I was unable to find what -on could stand for. In my little test this key has not affected the output in any way, as far as I recognize, while -O3 resulted in smaller executable.
I presumed, that gcc must be case sensitive everywhere - be it Windows or Unix-like OS with case-sensitive FS, at least wrt to command options. And I expected gcc to bail out with error message unrecognized option '-o3' when fed it with -o3, however, it did not.
gcc --version is
gcc (Gentoo 5.4.0-r3 p1.3, pie-0.6.5) 5.4.0
Copyright (C) 2015 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.
arch output:
x86_64
The -o option sets the output file to write to, so compiling with -o3 will cause the compiler to generate an object or executable file called 3

The syntax of the command is incorrect while compiling Clang with GCC-4.9.1_x64

After coming across some problems regarding cmake and gcc-4.9.1 on windows system, and spending more than 2 hours of building llvm with clang I got a really nice error that I can't seem to find information on. I've done everything according to documentation and here's the story-teller error message that make gives me:
Scanning dependencies of target LTO_exports
[ 69%] Creating export file for LTO
The syntax of the command is incorrect.
make[2]: *** [tools/lto/LTO.def] Error 1
make[1]: *** [tools/lto/CMakeFiles/LTO_exports.dir/all] Error 2
make: *** [all] Error 2
That is all to it, no other detail available at all. I've checked the LTO.def file since it references that. The file contains one single entry: "EXPORTS[CR][LF]". The LTO_exports.dir/all contains the following files:
build.make
cmake_clean.cmake
depend.internal
depend.make
DependInfo.cmake
progress.make
I haven't touched these files at all. I used the following cmake command before actually using make.
C:\LLVM_Binaries>cmake -G"MinGW Makefiles" -DCMAKE_C_COMPILER="C:/MinGW/bin/gcc.exe" -DCMAKE_CXX_COMPILER="C:/MinGW/bin/g++.exe" -DCMAKE_MAKE_PROGRAM="C:/MinGW/bin/make.exe" -DCMAKE_BUILD_TYPE=Release ..\LLVM
Also here're the details of gcc g++ and make:
gcc --version
gcc (GCC) 4.9.1
Copyright (C) 2014 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.
g++ --version
g++ (GCC) 4.9.1
Copyright (C) 2014 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.
make -v
GNU Make 3.82
Built for x86_64-w64-mingw32
This program is built by Equation Solution <http://www.Equation.com>
for Windows.
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Anyone else experienced this problem and managed to build llvm with clang on 64bit Windows operating system?
#Edit (output of make VERBOSE=1)
Scanning dependencies of target LTO_exports
make[2]: Leaving directory `C:/LLVM_Binaries'
make -f tools\lto\CMakeFiles\LTO_exports.dir\build.make tools/lto/CMakeFiles/LTO_exports.dir/build
make[2]: Entering directory `C:/LLVM_Binaries'
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_progress_report C:\LLVM_Binaries\CMakeFiles
[ 69%] Creating export file for LTO
cd /d C:\LLVM_Binaries\tools\lto && "C:\Program Files (x86)\CMake\bin\cmake.exe" -E echo EXPORTS > LTO.def
cd /d C:\LLVM_Binaries\tools\lto && type C:/LLVM/tools/lto/lto.exports >> LTO.def
The syntax of the command is incorrect.
make[2]: *** [tools/lto/LTO.def] Error 1
make[2]: Leaving directory `C:/LLVM_Binaries'
make[1]: *** [tools/lto/CMakeFiles/LTO_exports.dir/all] Error 2
make[1]: Leaving directory `C:/LLVM_Binaries'
make: *** [all] Error 2
After digging in this issue quite deeply I've successfully built it. For anyone who might get this error while compiling llvm&clang on windows with gcc: http://reviews.llvm.org/D5476#5e5fbd1d
Of course you can avoid this problem by using the sources from their SVN instead of downloading the latest stable release from http://llvm.org/releases/download.html#3.5
Did you run the configuration file before running cmake?
sh ./configure
If that doesn't work, try using the 32 bit version of your compiler. If that works, you can build for 64-bit by compiling a GCC 32-bit cross compiler.
You could also try Cygwin - perhaps that might help. Or if you're really stuck you could go backtracking and run the problematic command from a terminal, not a makefile.

Resources