CCCONFIG(1)
π CCCONFIG(1) π
okay bestie, sit down, grab a boba, because we're about to talk about ccconfig β a lil Perl script from the User Contributed Perl Documentation section of the manual. it's giving "niche tool that absolutely ate" and i'm obsessed. π«Ά
β¨ NAME β¨
ccconfig β get a Convert::Binary::C configuration for a compiler. literally what it says on the tin, no cap. π
πΈ SYNOPSIS πΈ
ccconfig options [-- compiler-options]
options:
-c
--cc compiler compiler executable to test
default: auto-determined
-o
--output-file file output filename
default: output to stdout
-f
--output-format format output format
default: dumper
--basename name basename of the temporary test files
default: _t_e_s_t
-I
--inc-path path manually set compiler include path
--preprocess rule compiler rule for preprocessing
--compile-obj rule compiler rule for compiling objects
--compile-exe rule compiler rule for compiling executables
--c-ext ext extension of C source files
--pp-ext ext extension of preprocessor output files
--obj-ext ext extension of object files
--exe-ext ext extension of executable files
--nodelete don't delete temporary files
--norun don't try to run executables
--quiet don't display anything
--nostatus don't display status indicator
--version print version number
--debug debug mode
Placeholders allowed in compiler rules:
%c C source file
%o object file
%e executable file
%i preprocessor output file
| result is written to stdout (only at end of rule)
π¦ DESCRIPTION π¦
so ccconfig will try to determine a usable configuration for Convert::Binary::C by testing a compiler executable. and here's the slay part: it is not necessary that the binaries generated by the compiler can be executed, so ccconfig can also be used for cross-compilers. cross-compiler girlies, this one's for you. π
β οΈ real talk though: this tool is still experimental, and you should neither rely on its output without checking, nor expect it to work in your environment. it's giving "trust but verify", fr fr. π
π OPTIONS π
π
--cc compiler
this option lets you explicitly specify a compiler executable. it's especially useful if you don't want to use your system compiler (valid, honestly). if this option isn't given, ccconfig tries to guess a compiler. it's guessing bestie, be nice to it.
π
--output-file file
write the Convert::Binary::C configuration to the specified file. the default is to write the configuration to stdout. iconic default behavior, honestly.
π
--output-format format
specify the output format of the Convert::Binary::C configuration. the following formats are currently supported:
dumper Output a %config hash using Data::Dumper
require Output in a format suitable for require
the default is dumper.
π
--basename name
allows you to change the base name of the temporary test files. this is used along with the various -ext options to build the filenames of C source files, preprocessor output files, object files and executables. name your children, bestie. π
π
--inc-path path
this option allows you to manually set the include path of the compiler. this is useful if ccconfig cannot determine the include path automatically, most probably because it cannot parse the preprocessor output. this option can be specified more than once. stack 'em up. β¨
π
--preprocess rule
using this option, you can specify a rule that ccconfig uses to run the compiler to get preprocessor output. most compilers write the preprocessor output to standard output when given the -E option, i.e.
cc -E foo.c
will preprocess foo.c to standard output. the corresponding rule for ccconfig would be:
ccconfig --preprocess='-E %c |'
the %c will be replaced with the C source filename, and the pipe symbol signals that the result will be written to standard output.
the following placeholders can be used in ccconfig rules:
%c C source file
%o object file
%e executable file
%i preprocessor output file
usually, ccconfig tries to figure out the correct rules on its own. it's a smart girlie. π§
π
--compile-obj rule
like --preprocess, this option allows you to define a rule for how to compile an object file. for most compilers, this rule will be something like
ccconfig --compile-obj='-c -o %o %c'
π
--compile-exe rule
like --preprocess, this option allows you to define a rule for how to compile an executable file. for most compilers, this rule will be something like
ccconfig --compile-exe='-o %e %c'
π‘ note that it is sufficient to specify either--compile-objor--compile-exe. so if your compiler can only create object files, that's just fine. no pressure. π«Ά
π
--c-ext
this option is used along with --basename to build the name of a C source file. this is usually set to .c.
π
--pp-ext
this option is used along with --basename to build the name of a preprocessor output file.
π
--obj-ext
this option is used along with --basename to build the name of an object file.
π
--exe-ext
this option is used along with --basename to build the name of an executable file.
π
--nodelete
don't attempt to delete temporary files that have been created by the compiler. normally, ccconfig will look for all files with the same basename as the temporary test file and delete them. so like, if you pass this, it's gonna leave a little mess behind. your call. π
π
--norun
you can specify this option if the executables generated by your compiler cannot be run on your machine, i.e. if you have a cross-compiler. however, ccconfig will automatically find out that it cannot run the executables. it's perceptive like that. π
when this option is set, a different set of algorithms is used to determine a couple of configuration settings. these algorithms are all based upon placing a special signature in the object file. they are less reliable than the standard algorithms, so you shouldn't use them unless you have to. periodt.
π
--quiet
don't display anything except for the final configuration. minimalism era. π€«
π
--nostatus
hide the status indicator. recommended if you want to redirect the script output to a file:
ccconfig --nostatus >config.pl 2>ccconfig.log
π
--version
writes the program name, version and path to standard output.
π
--debug
generate tons of debug output. don't use unless you know what you're doing. fr fr, i mean it, this one goes brrrr. π
π EXAMPLES π
normally, a simple
ccconfig
without arguments is enough if you want the configuration for your system compiler. while ccconfig is running, it will write lots of status information to stderr. when it's done, it will usually dump a Perl hash table to stdout which can be directly used as a configuration for Convert::Binary::C. chef's kiss. β¨
if you want the configuration for a different compiler, or ccconfig cannot determine your system compiler automatically, use
ccconfig -c gcc32
if your compiler's name is gcc32.
if you want to pass additional options to the compiler, you can do so after a double-dash on the command line:
ccconfig -- -g -DDEBUGGING
or
ccconfig -c gcc32 -- -ansi -fshort-enums
if you'd like to interface with the Perl core, you may find a suitable configuration using something like:
ccconfig --cc=`perl -MConfig -e 'print $Config{cc}'` \
-- `perl -MConfig -e 'print $Config{ccflags}'`
π COPYRIGHT π
Copyright (c) 2002-2024 Marcus Holland-Moritz. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. legal bestie moment, we love to see it. π
π SEE ALSO π
See Convert::Binary::C. that's the whole vibe, go read it. π¦
and that's the tea, bestie!! this page came to you from perl v5.42.0, dated 2025-09-08, and it's part of the User Contributed Perl Documentation collection. stay config'd, stay slay. π
β¨πΈ
π¦ where this page comes from
- fedora 43: perl-Convert-Binary-C 0.86-1.fc43 Β· GPL-1.0-or-later OR Artistic-1.0-Perl
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms