strftime is a standard Unix C function. The version of strftime in glibc supports some extensions. Using autoconf, is there an easy way to test whether strftime supports these extensions?
Failing that, is there an easy way in autoconf to test whether the standard library is the GNU glibc?
Related
I want my Windows C program compiled with GCC on MinGW64 toolchain to output inf, -inf etc. ANSI values instead of Windows specific one like 1.#IND.
So far I was adding the following line before including stdio.h to my header files to achieve it:
#define __USE_MINGW_ANSI_STDIO 1
That worked great and didn't cause any problems when using MSYS2 based distribution. That changed when I installed mingw64 build from winlibs (I need an older version of GCC than MSYS2 currently provides as GCC 12 introduced very significant performance regressions). The line gave me warnings about redefining macros. I've then found a post from one of the designers of MinGW system about it. Apparently that's an internal macro and shouldn't be used by the user. The suggested way is to define _MINGW_FEATURES so I tried:
__MINGW_FEATURES__ _MINGW_ANSI_STDIO
instead. While that worked for ANSI output it unfortunately resulted in the compiler not recognizing SCNu8 (or C99 standard %hhu) modifiers anymore.
What's the correct way to use GCC based on MinGW toolchain to both use ANSI STDIO output and allow C99 printf/scanf modifiers (like %hhu or at least SCNu8).
GNU GCC Compiler Environment Variables Default-Search-Path — I am trying to change default values of GCC environment variables to new custom values so that the default search path will contain any needed additional libraries or include header files that I would like to use on a regular basis.
My version of GNU GCC is: gcc (MinGW.org GCC Build-2) 9.2.0
Include directories for .h header files for this <…> not "…" which would be in the same directory as .c file extension.
Include Header Directories:
CPATH
C_INCLUDE_PATH
CPLUS_INCLUDE_PATH
OBJC_INCLUDE_PATH
Library File Directories:
LIBRARY_PATH
I realized that these are Windows Environment Variables.
And That I could Simply just create Windows User Environment Variables.
Here is a command which will show default search paths for GNU GCC Compiler.
cpp -v
This shows include directory default search path.
gcc -print-search-dirs
This shows library directory default search path.
This Command Prompt Command tells me the default-search-paths which are set during installation of GNU GCC Compiler I assume these are considered Environment Variables and I am looking to see if anyone on the web could give me any urls in regards to changing this default search path value.
Here are a few links related to what I am doing. I used that information although I was still unable to accomplish what I was intending to accomplish.
GCC environment variables
C Preprocessor search path
C preprocessor environment variables
GCC configuration
Recent GCC compilers have some (optional) .spec files.
You could edit yours, and that file drives the actual compilation processes. As you know, gcc is mostly starting some cc1 / cc1plus internal program (then ld)
But I recommend to not edit your .spec file.
Instead of that, configure your build procedure, e.g. edit your Makefile for GNU make or your build.ninja file (actually, the generator of that file) for ninja builder.
Of course, read the chapter about Invoking GCC.
BTW, GNU make has a lot of built-in rules. Use make -p to understand them.
You could also take inspiration from GNU autoconf.
You could also code your own GCC plugin, implementing your own #pragma which would customize the behavior of gcc. I am not sure it is a good idea.
How to change the default-search-path values?
don't do that, learn to use GCC instead
You might want, from time to time, to compile your code with Clang, to check that your code base is not tied to one particular compiler.
You could use Frama-C or the Clang static analyzer on your C code. In some cases, some bugs could be found at compile time. You certainly want to pass explicitly both -Wall and -Wextra to gcc (and notice that clang accepts them also)
PS. This is from a GNU/Linux perspective. Adapt that to your proprietary operating system. Or consider getting the permission to switch to Linux (see also this draft report funded by the CHARIOT European project).
I have recently been reading up on linkers and I'm having trouble understanding this compilation code. If I were to run gcc -Wl,--hash-style=both example.c, what difference will it make as opposed to me simply running gcc example.c. And also, what does --hash-style means
what does --hash-style means
--hash-style allows you to change the format of hashtable which is used for runtime symbol resolution (see Drepper's article, section "The GNU-style Hash Table" for details). The GNU hashtable format is said to be slightly faster.
If I were to run gcc -Wl,--hash-style=both example.c,
what difference will it make as opposed to me simply running gcc example.c
It depends on how your distro's GCC was configured. AFAIK most use either both or gnu styles by default. Both simply means that linked files will include, um, both gnu and sysv hashtables. This shouldn't matter unless you try to run your program on a system with dynamic linker which does not understand GNU hashtables. In that case, if program was built with -Wl,--hash-style=gnu, you'll get an error at startup about unsupported hashtable format.
Is there an option to GCC that changes the path of the assembler it uses? I'm getting errors from Solaris /usr/ccs/bin/as when using GCC to attempt to compile Haskell, but I've got a copy of GNU as in my path so when I type which as and as --version they use the GNU version, not the Solaris version. Unfortunately it seems GCC ignores the GNU version in the path and goes to the Solaris version. I'm trying to build Haskell on Solaris and I don't think it sits well with the Solaris assembler. I hope I can change this behaviour with a simple wrapper script so I don't have to recompile GCC.
Specifying the assembler to be used is not possible at run time. It has to be done when configuring gcc:
--with-gnu-as
Specify that the compiler should assume that the assembler it finds is the GNU
assembler. However, this does not modify the rules to find an assembler and will
result in confusion if the assembler found is not actually the GNU assembler.
(Confusion may also result if the compiler finds the GNU assembler but has not
been configured with --with-gnu-as.)
Note the part I've put in italics. Of course you could temporarily change /usr/ccs/bin/as to call the gnu assembler (provided you have the necessary permissions), but the above seems to suggest that you'll very likely run into problems. The gcc build process actually checks the features the assembler supports and generates code for exactly that assembler.
I suggest you build a new version of gcc first (configured to use the gnu tools), and then use that to build ghc.
No matter how hard I google, I can't seem to find a (relatively) easy-to-follow instruction on how to install the GNU Assembler on a mac.
I know I can use gcc -c (Apple Clang on a Mac) to assemble .s / .S files, but I want to use actual GNU Binutils as.
The GNU assembler cannot (yet) be used to create native object files (of Mach-O format). But you can of course use it to cross-assemble for some non-native object format, if that is what you want.
yasm works on Mac OSX (I got it from Homebrew), and it has a GNU as syntax parser which can be enabled with -p gas (it may be necessary to also add -r gas). It is not 100% complete, but it covers mostly everything. It can output to a variety of object formats (if cross-compiling is necessary), and in my opinion it's pretty cool. You can also use NASM syntax (which is completely supported) using -p nasm (again, -r nasm may be necessary).
Sorry about necroposting, but this is a still-relevant question and I believe that it needs an acceptable answer.
The gnu assembler is already installed on your mac (assuming that you installed the dev tools package). If you want to avoid XCode, you can invoke it from the command line with as, or with the preprocessor by using gcc yourfile.s $(OPTIONS).
Edit: as now points to the clang assembler; at the time this answer was written it pointed to (Apple's build of) the GNU assembler.
Maybe as instead of gas ? If you want to have gas as command invoke this: echo "alias gas=as" >> $HOME/.profile
It was installed on my Mac Lion when i opened the terminal and typed it. It might have been because of MacPorts and/or XCode as mentioned in the comments of a previous answer.