I have a cabal project, which I'm building with new-build. I have configured my library to use -O0 when I pass a dev flag, and to use -O2 for production builds.
The relevant stanza in my cabal file is
if (flag(dev)) || (flag(library-only))
ghc-options: -O0
cpp-options: -DDEVELOPMENT
else
ghc-options: -O2
However, if I do cabal new-build -f dev, cabal passes the -O1 option for some reason.
I can get around this by passing in --disable-optimization, but I'm curious why -f dev behaves this way
As far as I know, this is because cabal passes -O1 by default, and adding the -O0 flag doesn't tell it to not pass the other flag :-)
Related
I am currently using the following flags for my gcc compiler:
gcc -std=c99 -pedantic -Wall D_DEFAULT_SOURCE -g -c filename.c
But how can I make the output as verbose as possible? The error messages I am getting in C are not as nice as I am used to from more high level languages and I want to get as much information out of the gcc compiler as possible.
This is a summary of all comments I've received on this post:
These flags are the best you can use to make your compiler as verbose as
possible:
-pedantic -Wall -Wextra -Wwrite-strings -g3
Other flags such as -v and the entire -d* family will make the compilation process more verbose but won't enhance the error messages you are getting.
Check your current version with gcc --version. To get the newest gcc Version (i.e. gcc 12.2 since August 19, 2022) you might have to clone the gcc repository and build it yourself based on the distro (check via lsb_release -d) you are using.
Check this stackoverflow question out to install gcc 12.2 on Ubuntu.
Alternatively you could also directly get gcc-11 from apt without upgrading to the latest bleeding edge ubuntu (don't forget to use gcc-11 instead of gcc afterwards to compile).
When running the command:
clang --target=wasm32 -nostdlib -Wl, --no-entry -Wl, --export-all howold.c -o howold.wasm
I get the following errors:
clang-14: error: unsupported option '--no-entry'
clang-14: error: unsupported option '--export-all'
I installed LLVM using brew install llvm and linked it properly with brew link llvm, then ran source .zshrc.
Does macOS not support these directives or am I missing an install or command somewhere? I am new to LLVM and clang on macOS so this may be an installation problem but not entirely sure.
To pass arguments to the linker, there shouldn't be a space after -Wl,. With the extra space, you're trying to give the --no-entry option to clang itself, which isn't valid.
Try this:
clang --target=wasm32 -nostdlib -Wl,--no-entry -Wl,--export-all howold.c -o howold.wasm
I have an installation of DPDK and I'm trying to compile code with it. This worked on my WSL machine, however on the test server, with the same install of dpdk, I'm getting the error:
/usr/local/include/rte_mempool.h: error: unknown type name 'ssize_t'
I've noticed this header does not include /sys/types.h, but it also doesn't include that on the machine that this works on. I don't know where it's supposed to come from, but it's coming from somewhere.
How do I get these headers to be aware of ssize_t?
As noted in a comment:
The compiler options include -std=c99 -O3 -march=native -I/usr/local/include -include rte_config.h, and a whole bunch of -l options (dpdk's make structure adds these in). This prompted me to run gcc --version and the working one is Ubuntu gcc 9.3.0 and the broken one is gcc 5.4.0. Seems like it might be an incompatibility between dpdk and the gcc installed.
As mentioned in the comments by #JonathanLeffier, the root cause of the issue is including sys/types.h when gcc option --std=c99 is passed. The easiest fix without modifying the DPDK or sample code is to include the path to types.h as part of cflags.
If the native build is for x86_64 target, follow these steps:
execute find /usr/include/ -name types.h to identify the right file for local build (this is because the current cflags has -march=native)
modify the CFLAGS from -std=c99 -O3 -march=native -I/usr/local/include -include rte_config.h to -std=c99 -O3 -march=native -I/usr/local/include -include rte_config.h --include=/usr/include/[target-machine]/sys/types.h
Note: In my humble suggestion please use pkg-config for populating the right CFLAGS and LDFLAGS for both shared and static binary.
I've used linuxbrew to install gcc 5.3 on a machine on which I don't have sudo access. I now want to link with X11:
> gcc test.c -lX11
ld: cannot find -lX11
I've checked that libX11.so exists in /usr/lib64/ which is on the compiler's LIBRARY_PATH. If I use the system's gcc it works fine, but I need a newer version to compile my actual program.
use -L flag, like this -L/usr/lib64, or you can specify full path to library like this gcc test.c /usr/lib64/libX11.so
According to this comment by a linuxbrew developer,
linuxbrewed gcc removes /usr/lib64 from the library path because mixing system libraries with brewed libraries creates havoc.
The solution is to brew install linuxbrew/xorg/xorg.
When I compile a simple Hello World! program that uses the sscanf function on my local Debian lenny x64, it works. But when I upload the same program to the server running CentOS x86, it will not work. If I do not use sscanf, then the program works on both computers.
gcc -std=c99 -O2 -pipe -m32
If I compile it with sscanf but without -std=c99, then it works on both computers.
gcc -O2 -pipe -m32
What is the problem with sscanf and c99 on CentOS x86 ? I thought that compiling with the -m32 flag would work on all Linuxes ? (I have limited access to the CentOS server, so I do not have access to error messages.)
Probably the CentOS box is using an old version of glibc. Since the nonstandard GNU extensions to their scanf implementation ended up making glibc conflict with c99, they added a nasty hack of redirecting *scanf to __isoc99_*scanf when -std=c99 is in use; if your copy of glibc is missing the __isoc99_sscanf symbol, the program will then fail to run.
Static linking, or linking to a different libc without ugly backwardsness-compatibility hacks, would solve the problem.
Are you uploading the binary or the source and then recompiling? If you are uploading the binary, you are probably running into a library compatibility issue between Debian and CentOS.
If that is the case, upload the source only and recompile on CentOS.
If you do not have permission to compile # CentOS, then try compiling a static binary. You can use dietlibc which makes smaller binaries than glibc or try EGLIBC which is the default C library that Debian will use starting Debian "squeeze".
I came up with the similar problem, it works # Ubuntu 64-bit, but the compile fails # CenseOS 64-bit (REHL5 desktop):
the error message is:
undefined reference to `__isoc99_sscanf#GLIBC_2.7'
when i copied the executable file compiled #Ubuntu to REHL5, and run it another error appeared:
elf file os abi invalid
it is compiled without flag -std=c99, i'm a newbie at C, and looking forword some workarounds, ex. add some flag.
Makefile:
CC=gcc
CCFLAGS= -Wall -O2 -DLINUX -I../include
demos:linuxdemo.c
$(CC) $(CCFLAGS) -o demoA linuxdemo.c -L../lib -lsense4 -lusb
$(CC) $(CCFLAGS) -o demoSO linuxdemo.c -lusb -lsense4
clean:
rm -f demoA
rm -f demoSO
You need to update your glibc to 2.7
download the rpm package from here:
http://archive.fedoraproject.org/pub/archive/fedora/linux/releases/8/Everything/x86_64/os/Packages/
needs:
libc-common-2.7-2.x86_64.rpm
glibc-headers-2.7-2.x86_64.rpm
glibc-devel-2.7-2.x86_64.rpm
glibc-2.7-2.x86_64.rpm
command:
rpm -Uvh --aid --nodeps glibc-common-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-headers-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-devel-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-2.7-2.x86_64.rpm