When I compile a hello.c program that contain a fuse.h header file it shows this error. - #error add -D_FILE_OFFSET_BITS-64 to your compile flags. while accessing fuse_common.h.
Previously, I have installed fuse filesystem from fuse.sourceforge.net and run an example from that fuse-2.9.3. Could anyone know how to fix this error. I am using Ubuntu 14.04 LTS - i386 (32 bit) on VM of oracle.
Try to modify the Makefile to add a line:
CFLAGS += -D_FILE_OFFSET_BITS=64
Alternately, you can add a line in hello.c before you include fuse.h:
#define _FILE_OFFSET_BITS 64
#include <fuse.h>
Related
Here's the error that I am getting and none of the online solutions are effectively fixing the issues that I am having. Just adding #include <stdint.h> breaks the compilation of my code. I tried installing multilib but the library seems to have no support on Ubuntu. I also tried some of the compatibility libraries but to no avail.
clang -O2 -target bpf -c hello.c -o hello.o
In file included from hello.c:2:
In file included from /usr/lib/llvm-11/lib/clang/11.0.0/include/stdint.h:52:
/usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found
#include <bits/libc-header-start.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
The code for reference. I am trying to run a compiled version of uBPF on an ARM device
#include <stdint.h>
static int idouble(int a)
{
return (a * 2);
}
int bpf_prog(void *ctx)
{
int a = 1;
a = idouble(a);
return (a);
}
This question is based on this Klyr's tutorial on how to setup user input with uBPF.
I was able to have my issue fixed actually. ARM does not have a gcc-multilib equivalent so you must install gcc-multilib-arm-linux-gnueabihf for this to work. When trying to compile and target with Clang, you must first
cd /usr/include/aarch64-linux-gnu
then
sudo cp -r . ..
It's a hacky solution but it will let you import libraries as you see fit
I have a C file, which uses multiple lib files.
I am trying to compile the file in the following way:
gcc -o myprogram main.c list.lib filelib.lib
However, when trying to compile I get a bunch of undefined reference errors of all the lib functions that I'm using.
I came accross a solution on the internet and tried the following:
gcc -o myprogram main.c -l list -l filelib
Now I get the following errors:
cannot find -llist
cannot fint -lfilelib
What am I doing wrong?
Edit:
Both the libs were originally created using Visual Studio 2019, Release mode x64.
I am using Windows 10, 64 bits architecture.
In the folder I'm running gcc from I have the following files:
main.c
list.lib (copied from VS)
list.h (copied form VS)
filelib.lib (copied from VS)
filelib.h (copied from VS)
In my lib code in VS I made sure the functions have c-linkage:
#ifdef __cplusplus
#define C_LINKAGE extern "C"
#else
#define C_LINKAGE
#endif
(each declared function in both the libs starts with the C_LINKAGE macro)
The .lib files are MSVC specific, gcc can not handle them, gcc can handle .a libraries or dll's (on windows)
If you want to use gcc, rebuild the libraries with gcc, or let MSVC create DLL's.
Or stick to microsoft and use MSVC for everything.
Just put "-l:liblist.lib" instead of "-llist" when the suffix is not ".a". That should solve the "Not found" issue at least.
I would like to give a BIG thanks to #Harkaitz for this hint.
I spent several days to figure out why GCC (arm cross compile on Windows) was not able to find my libs in group. I wish those spelling issues to be more documented somewhere...
Basically the ':' in between '-l' and 'lib.a' was solving the issue, like this:
-L./my_path_to_libs -Xlinker --start-group -l:libmain.a -Xlinker --end-group
Depending on arm gcc verzion, -Xlinker could be -Wl
The Coverity Scan Build Tool fails to compile any C file that includes <stdlib.h> on Ubuntu 18.04 when _GNU_SOURCE is defined:
$ cat > main.c
#include <stdlib.h>
int main() {
}
$
$ gcc -D_GNU_SOURCE=1 -o main main.c
$
$ /opt/cov-analysis/bin/cov-build --dir cov-int gcc -D_GNU_SOURCE=1 -o main main.c
Coverity Build Capture (64-bit) version 2017.07 on Linux 4.15.0-20-generic x86_64
...
[WARNING] Emitted 0 C/C++ compilation units (0%) successfully
...
$
The same build works perfectly on Ubuntu 16.04 or without _GNU_SOURCE defined:
$ /volatile/local/cov-analysis/bin/cov-build --dir cov-int gcc -o main main.c
Coverity Build Capture (64-bit) version 2017.07 on Linux 4.15.0-20-generic x86_64
...
Emitted 1 C/C++ compilation units (100%) successfully
...
$
How to get Coverity Scan to build C sources with _GNU_SOURCEdefined on Ubuntu 18.04?
For those interested file cov-int/build-log.txt can be found here:
https://gist.github.com/DimitriPapadopoulos/0dcd9018eed26401cc6095087d9cc1d5
After contacting Coverity support, it appears this is known bug. They suggested I work around it by switching from the default Ubuntu 18.04 compiler (GCC 7) to the previous version (GCC 6):
sudo apt install gcc-6
Indeed _Float32, _Float32x, _Float64, _Float64x and _Float128 were introduced in GCC 7.
Coverity is failing to define the types GCC would define, but then it's claiming to be GCC anyway. Here's a workaround: https://gist.github.com/vathpela/0cede6d6eb5b0ec0791c6afc4282c340#file-fix_coverity-h
Just be sure you do:
#include "fix_coverity.h"
before stdlib.h gets included, whether directly or indirectly.
I am trying to compile a C program that requires Image Magick's MagickWand.h:
#include "wand/MagickWand.h"
But my Image Magick was installed through Homebrew on my Mac so I changed the include to the actual location:
#include </usr/local/Cellar/imagemagick/6.8.9-7/include/ImageMagick-6/wand/MagickWand.h>
However, when I compiled the program I received the following error:
/usr/local/Cellar/imagemagick/6.8.9-7/include/ImageMagick-6/wand/MagickWand.h:71:10: fatal error: 'wand/method-attribute.h' file not found
#include "wand/method-attribute.h"
Now I've been going into the .h files when this error crops up and changing their #includes so that they are pointed correctly (because that appears to be the problem), but there is always a new error here and I'd rather not spend hours manually updating these because of a Homebrew install. Does anyone have any suggestions on how to fix this without manually updating each file? I'm not sure exactly what the problem is so perhaps there is a more elegant solution.
Your code should include the MagickWand library as system headers, and keep the generic path. This will keep your future compiling from breaking when the system/library updates.
#include <wand/MagickWand.h>
Tell your C compiler where homebrew installed ImageMagick by setting the preprocessor include flag -I, and linking/library options with the -L & -l flags.
example:
clang -I/usr/local/Cellar/imagemagick/6.8.9-7/include/ImageMagick-6 \
myProject.c -o myProject.o \
-L/usr/local/Cellar/imagemagick/6.8.9-7/lib \
-lMagickWand-6.Q16 \
-lMagickCore-6.Q1
To simplify the whole process, ImageMagick ships MagickWand-config utility. This will take care of libs, includes, and definitions for you.
example:
CFLAGS=$(MagickWand-config --cflags)
LFLAGS=$(MagickWand-config --libs)
clang $CFLAGS myProject.c -o myProject.o $LFLAGS
I have MinGW and I wish to compile the SQLite amalgamation source into a 64-bit dll. I'm fairly new to this sort of compilation and my efforts so far have resulted in failure. (I first started using the autoconf amalgamation and used the configure & make tool on Linux. But apparently that will never work for Windows binaries.)
Anyway, I've been told I need the following preprocessor defines:
Here are the compiler pre-processor defines I use for a 64-bit release build:
WIN64 NDEBUG
_WINDOWS
_USRDLL
NO_TCL
_CRT_SECURE_NO_DEPRECATE
THREADSAFE=1
TEMP_STORE=1
SQLITE_MAX_EXPR_DEPTH=0
Here are the compiler pre-processor defines I use for a 32-bit release build:
WIN32
NDEBUG
_WINDOWS
_USRDLL
NO_TCL
_CRT_SECURE_NO_DEPRECATE
THREADSAFE=1
TEMP_STORE=1
SQLITE_MAX_EXPR_DEPTH=0
I had no idea where to put these in. I eventually took an educated guess, made a new file (for neatness) called sqlite3w64.h and pasted in the following:
#define WIN64 NDEBUG
#define _WINDOWS
#define _USRDLL
#define NO_TCL
#define _CRT_SECURE_NO_DEPRECATE
#define THREADSAFE 1
#define TEMP_STORE 1
#define SQLITE_MAX_EXPR_DEPTH 0
I then compiled the source with the following command:
gcc sqlitew64.h sqlite3.h sqlite3ext.h shell.c sqlite3.c -o sqlite_x64.dll
What resulted was a 733KB DLL file. Nice! Did it actually work? Did it nuts - I got a BadImageFormatException. I also then tried doing an x86 compilation using the same method. Once again, I got a 733KB DLL file (that's odd?) and once again, I got a BadImageFormatException.
Help.
Update
Used the following command instead:
gcc -shared -DWIN64 -DNDEBUG -D_WINDOWS -D_USRDLL -DNO_TCL -D_CRT_SECURE_NO_DEPRECATE -DTHREADSAFE=1 -DTEMP_STORE=1 -DSQLITE_MAX_EXPR_DEPTH=0 -I. shell.c sqlite3.c -o sqlite_x64.dll -Wl,--out-implib,sqlite3.a
Resulted in a 740KB DLL file which still gives a BadImageFormatException.
Final Update
Turns out my MinGW build was 32-bit only. Getting a 64-bit version then allowed me to make SQLite for 64-bit. Adding the flag -m64 sets the compiler into 64-bit mode.
64-bit:
gcc -shared -DWIN64 -DNDEBUG -D_WINDOWS -D_USRDLL -DNO_TCL -D_CRT_SECURE_NO_DEPRECATE -DTHREADSAFE=1 -DTEMP_STORE=1 -DSQLITE_MAX_EXPR_DEPTH=0 -m64 -I. shell.c sqlite3.c -o sqlite3_x64.dll -Wl,--out-implib,sqlite3_x64.a
32-bit:
gcc -shared -DWIN32 -D_WINDOWS -D_USRDLL -DNO_TCL -D_CRT_SECURE_NO_DEPRECATE -DTHREADSAFE=1 -DTEMP_STORE=1 -DSQLITE_MAX_EXPR_DEPTH=0 -m32 -I. shell.c sqlite3.c -o sqlite3_x86.dll -Wl,--out-implib,sqlite3_x86.a
MinGW-64 Precompiled: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-bin_i686-mingw_20111220.zip/download?use_mirror=ignum
Installation Instructions: http://code.google.com/p/tonatiuh/wiki/InstallingMinGWForWindows64
You are compiling to an EXE. Calling it a DLL won't magically make it a DLL.
You need to pass special linker options to gcc to make it create DLLs.
Quoted from Mingw site: (Sort of, I replaced g++ with gcc)
gcc -c -DBUILDING_EXAMPLE_DLL example_dll.cpp
gcc -shared -o example_dll.dll example_dll.o -Wl,--out-implib,libexample_dll.a
The page also explains that functions you want your DLL to export, must be declared with __declspec(dllexport). (Further down, there is an example on how to export all global functions to the DLL, like usually happens in Unix.)
The -Wl argument to gcc is what tells gcc to pass on the further arguments --out-implib,libexample_dll.a to the linker.
I would also make 100% sure that the built DLL is actually a 64 bit DLL and not a 32 bit DLL. Do you have any way to check that? On Linux you can run the "file" command.
You can also try adding the -m64 option to the gcc commandline, that should force gcc to target the amd64 target.
If that doesn't work, you may have the wrong compiler altogether. Make sure you have the x86_64/amd64 version of the Mingw toolchain. Installation is as simple as finding the right ZIP, unpacking it, and setting the path.
If all of that fails, or if you just want to verify against a supposedly correctly compiled setup, try precompiled 64-bit binaries here or from here.
What would work in your case is this single link-and-compile command:
g++ -shared
-DWIN64
-DNDEBUG
-D_WINDOWS
-D_USRDLL
-DNO_TCL
-D_CRT_SECURE_NO_DEPRECATE
-DTHREADSAFE=1
-DTEMP_STORE=1
-DSQLITE_MAX_EXPR_DEPTH=0
-I.
shell.c sqlite3.c
-o sqlite_x64.dll
-Wl,--out-implib,libsqllite_x64.dll.a
The compile and link stage will be performed at once. The defined can be added on the commandline. The headers need not be compiled, but you need to pass the current directory as a header search directory, and specify the names of the dll and import file.