about summary refs log tree commit diff
path: root/configure
Commit message (Collapse)AuthorAgeFilesLines
* add m68k portRich Felker2018-06-191-0/+8
| | | | | | | | | | | | | three ABIs are supported: the default with 68881 80-bit fpu format and results returned in floating point registers, softfloat-only with the same format, and coldfire fpu with IEEE single/double only. only the first is tested at all, and only under qemu which has fpu emulation bugs. basic functionality smoke tests have been performed for the most common arch-specific breakage via libc-test and qemu user-level emulation. some sysvipc failures remain, but are shared with other big endian archs and will be fixed separately.
* use explicit dynamic-list rather than symbolic-functions for linkingRich Felker2018-04-171-4/+6
| | | | | | | | | | | | | | | | | | | | | we have always bound symbols at libc.so link time rather than runtime to minimize startup-time relocations and overhead of calls through the PLT, and possibly also to preclude interposition that would not work correctly anyway if allowed. historically, binding at link-time was also necessary for the dynamic linker to work, but the dynamic linker bootstrap overhaul in commit f3ddd173806fd5c60b3f034528ca24542aecc5b9 made it unnecessary. our use of -Bsymbolic-functions, rather than -Bsymbolic, was chosen because the latter is incompatible with public global data; it makes it incompatible with copy relocations in the main program. however, not all global data needs to be public. by using --dynamic-list instead with an explicit list, we can reduce the number of symbolic relocations left for runtime. this change will also allow us to permit interposition of specific functions (e.g. the allocator) if/when we want to, by adding them to the dynamic list.
* fix detection of LIBCC for compiler-rt with clangMatúš Olekšák2018-02-211-0/+2
| | | | | | | | | | | Maintainer's note: at one point, -lcompiler_rt apparently worked, and may still work and be preferable if one has manually installed the library in a public lib directory. but with current versions of clang, the full pathname to the library file is needed. the original patch removed the -lcompiler_rt check; I have left it in place in case there are users depending on it, and since, when it does work, it's preferable so as not to code a dependency on the specific compiler version and paths in config.mak.
* better configure check for long double supportSzabolcs Nagy2018-02-071-3/+2
|
* disable global visibility override hack (vis.h) by defaultRich Felker2017-08-111-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | neither current compilers nor linkers treat protected visibility the way I expected, as having fixed source-level semantics rather than being dependent on target-specific ABI details, and change seems unlikely. while the use here does not actually depend on the specific semantics, at least some versions of some linkers, especially lld, refuse to allow linking to a libc.so where the symbols have protected visibility. this cannot be detected at configure-time because linking libc.so itself works fine, and because even if we could test linking an application against libc.so successfully, we could not justifiably assume that the same linker used to link libc.so would also be used later to link applications. disable the vis.h hack by default at the configure level, but add an explicit "auto" option to request the old configure-time detection rather than just removing it. this leaves it easy to evaluate whether it actually resulted in significant size or performance benefits while ensuring that out-of-the-box builds are not unlinkable for some users. fortunately, preliminary evaluation suggests that at least x86_64, arm, and aarch64 don't suffer at all from the change, and impact on other archs is low. if low is not low enough, it should not be hard to analyze where the significant PLT call ABI costs are present and mitigate them without the hack.
* fix clang CFLAGS checks and silence unused argument warningsDmitry Golovin2017-06-231-0/+8
|
* when building for arm as thumb2 code, also request assembly as thumbRich Felker2016-12-191-0/+4
| | | | | | all assembly is now thumb2-compatible. on existing targets this is at best a size optimization, but it will also facilitate porting to thumb2-isa-only arm variants.
* add s390x portBobby Bingham2016-11-111-0/+1
|
* configure: handle mipsisa64* triplet as a mips64 targetSzabolcs Nagy2016-08-301-1/+1
| | | | | the gnu config.sub script recognizes several mipsisa64* cpu types that musl supports as mips64 targets.
* add powerpc64 portBobby Bingham2016-05-081-1/+7
|
* fix redundant processing of --build flag in configure scriptLeMay, Michael2016-05-041-1/+1
| | | | | | | | The --build flag is listed in two case statement entries in configure, which causes the second entry to be ignored. This patch removes it from the first entry. Signed-off-by: Michael LeMay <michael.lemay@intel.com>
* follow standard configure behavior for cross compile prefixRich Felker2016-04-291-1/+13
| | | | | | | | | | | | | | | | the standard configure interface, which our configure script tries to implement, identifies cross compiling (build != host) and searches for the properly-prefixed cross tools. our script was not doing that, forcing users to explicitly provide either CC or a CROSS_COMPILE tool prefix, and the more common choice, just providing CC, was incomplete because the Makefile would still invoke the native ar and ranlib programs. this happened to work when building on ELF-based systems with GNU binutils, but could easily fail when cross-compiling from dissimilar systems. like before, and like the standard configure behavior, an explicit CC or CROSS_COMPILE variable on the command line or in the environment overrides the automatic prefixing.
* add mips n32 port (ILP32 ABI for mips64)Rich Felker2016-04-181-0/+1
| | | | based on patch submitted by Jaydeep Patil, with minor changes.
* add support for mips and mips64 r6 isaRich Felker2016-04-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | mips32r6 and mips64r6 are actually new isas at both the asm source and opcode levels (pre-r6 code cannot run on r6) and thus need to be treated as a new subarch. the following changes are made, some of which yield code generation improvements for non-r6 targets too: - add subarch logic in configure script and reloc.h files for dynamic linker name. - suppress use of .set mips2 asm directives (used to allow mips2 atomic instructions on baseline mips1 builds; the kernel has to emulate them on mips1) except when actually needed. they cause wrong instruction encodings on r6, and pessimize inlining on at least some compilers. - only hard-code sync instruction encoding on mips1. - use "ZC" constraint instead of "m" constraint for llsc memory operands on r6, where the ll/sc instructions no longer accept full 16-bit offsets. - only hard-code rdhwr instruction encoding with .word on targets (pre-r2) where it may need trap-and-emulate by the kernel. otherwise, just use the instruction mnemonic, and allow an arbitrary destination register to be used.
* make configure check for unsupported (SPE) powerpc hard-float modelsRich Felker2016-03-061-0/+2
| | | | | | the SPE ABI may be compatible with soft-float, but actually making it work requires some additional work, so for now it's best to make sure broken builds don't happen.
* add powerpc soft-float supportFelix Fietkau2016-03-061-0/+4
| | | | | | | | | Some PowerPC CPUs (e.g. Freescale MPC85xx) have a completely different instruction set for floating point operations (SPE). Executing regular PowerPC floating point instructions results in "Illegal instruction" errors. Make it possible to run these devices in soft-float mode.
* add mips64 portRich Felker2016-03-061-1/+7
| | | | | patch by Mahesh Bodapati and Jaydeep Patil of Imagination Technologies.
* add arch tuple matching for nt32 and nt64 in configureRich Felker2016-02-191-0/+2
| | | | | | | | | the nt32 and nt64 archs will be provided by the midipix project for building musl on top of its posix-like syscall layer for windows. at present the needed arch files are in a separate repository, but having the tuple matching in the upstream configure script should make it possible to overlay the arch files without needing any further patching.
* work around regression building for armhf with clang (compiler bug)Rich Felker2016-02-191-0/+14
| | | | | | | | | commit e4355bd6bec89688e8c739cd7b4c76e675643dca moved the math asm from external source files to inline asm, but unfortunately, all current releases of clang use the wrong inline asm constraint codes for float and double ("w" and "P" instead of "t" and "w", respectively). this patch adds detection for the bug in configure, and, for now, just disables the affected asm on broken clang versions.
* partly revert detection of broken float in configureRich Felker2016-02-181-1/+1
| | | | | | | | | commit 80fbaac4cd1930e9545a5d36bf46ae49011d2ce8 broke all soft-float archs, where gcc defines __GCC_IEC_559==0 because rounding modes and exception flags are not supported. for now, just check for __FAST_MATH__ as an indication of broken float. this won't detect all possible misconfigurations but it probably catches the most common one.
* make configure attempt to catch broken floating point CFLAGS/defaultsRich Felker2016-02-171-0/+10
|
* make configure accept -h as an alias for --helpRich Felker2016-02-021-1/+1
|
* don't suppress shared libc when linker lacks -Bsymbolic-functionsRich Felker2016-01-311-9/+4
| | | | | | | | | | | previous work overhauling the dynamic linker made it so that linking libc with -Bsymbolic-functions was no longer mandatory, but the configure logic that forced --disable-shared when ld failed to accept the option was left in place. this commit removes the hard-coded -Bsymbolic-functions from the Makefile and changes the configure test to one that simply adds it to the auto-detected LDFLAGS on success.
* add arch/generic include fallback to build rulesRich Felker2016-01-271-2/+3
| | | | | | this sets the stage for the first phase of the bits deduplication. bits headers which are identical for "most" archs will be moved to arch/generic/bits.
* remove unneeded -I options from configure test for may_alias attributeRich Felker2016-01-271-1/+1
| | | | | this test does not include anything, so the -I options are not useful and are just a maintenance burden if paths change.
* use same object files for libc.a and libc.so if compiler produces PICRich Felker2016-01-251-0/+10
| | | | | | | | | | | | | | | | now that .lo and .o files differ only by whether -fPIC is passed (and no longer at the source level based on the SHARED macro), it's possible to use the same object files for both static and shared libc when the compiler would produce PIC for the static files anyway. this happens if the user has included -fPIC in their CFLAGS or if the compiler has been configured to produce PIE by default. we use the .lo files for both, and still append -fPIC to the CFLAGS, rather than using the .o files so that libc.so does not break catastrophically if the user later removes -fPIC from CFLAGS in config.mak or on the make command line. this also ensures that we get full -fPIC in case -fpic, -fPIE, or some other lesser-PIC option was passed in CFLAGS.
* fix global visibility (vis.h) support for out-of-tree buildsRich Felker2016-01-201-1/+1
| | | | | | commit 2f853dd6b9a95d5b13ee8f9df762125e0588df5d failed to change the test for -include vis.h support to use $srcdir, so vis.h was always disabled by configure for out-of-tree builds.
* support out-of-tree buildPetr Hosek2016-01-171-5/+25
| | | | | | | | | | | | this change adds support for building musl outside of the source tree. the implementation is similar to autotools where running configure in a different directory creates config.mak in the current working directory and symlinks the makefile, which contains the logic for creating all necessary directories and resolving paths relative to the source directory. to support both in-tree and out-of-tree builds with implicit make rules, all object files are now placed into a separate directory.
* work around toolchains with broken visibility in libgcc/libpccRich Felker2015-11-071-0/+5
|
* have configure check/add --gc-sections linker optionRich Felker2015-11-041-0/+4
| | | | | | | | this allowing the linker to drop certain weak definitions that are only used as dummies for static linking. they could be eliminated for shared library builds using the preprocessor instead, but we are trying to transition to using the same object files for shared and static libc, so a link-time solution is preferable.
* have configure check/add linker options to reduce size lost to paddingRich Felker2015-11-041-0/+6
| | | | | | based on patch by Denys Vlasenko. sorting sections and common data symbols by alignment acts as an approximation for optimal packing, which the linker does not actually support.
* have configure check/add -ffunction-sections and -fdata-sectionsRich Felker2015-11-041-0/+11
| | | | | | | | | | | | | | | | | | based on patch by Denys Vlasenko. the original intent for using these options was to enable linking optimizations. these are immediately available for static linking applications to libc.a, and will also be used for linking libc.so in a subsequent commit. in addition to the original motives, this change works around a whole class of toolchain bugs where the compiler generates relative address expressions using a weak symbol and the assembler "optimizes out" the relocation which should result by using the weak definition. (see gas pr 18561 and gcc pr 66609, 68178, etc. for examples.) by having different functions and data objects in their own sections, all relative address expressions are cross-section and thus cannot be resolved to constants until link time. this allows us to retain support for affected compiler/assembler versions without invasive and fragile source-level workarounds.
* keep user-provided CFLAGS/LDFLAGS separate from those added by configureRich Felker2015-11-021-2/+4
| | | | | | this way, overriding these variables on the make command line (or just re-passing the originally-passed values when invoking make) won't suppress use of the flags added by configure.
* prevent user CFLAGS overrides from exposing executable stackRich Felker2015-10-231-7/+7
| | | | | | | | | | | the option to suppress executable stack tagging was placed in CFLAGS, which is treated as optional and overridable by the build system. if a user replaces CFLAGS after configure has run, it could get lost, resulting in a libc.so that's flagged as needing executable stack, which would cause the kernel to map the initial stack as executable. move -Wa,--noexecstack to CFLAGS_C99FSE, the make variable used for mandatory compiler options.
* suppress sh assembler rejection of instructions based on isa levelRich Felker2015-10-151-0/+1
| | | | | | we need access to all instructions in order for runtime selection of atomic model to work correctly. without this patch, some versions of gcc instruct gas to reject instructions outside the target isa level.
* eliminate protected-visibility data in libc.so with vis.h preincludeRich Felker2015-09-291-3/+11
| | | | | | | | | | | | | | | some newer binutils versions print scary warnings about protected data because most gcc versions fail to produce the right address references/relocations for such data that might be subject to copy relocations. originally vis.h explicitly assigned default visibility to all public data symbols to avoid this issue, but commit b8dda24fe1caa901a99580f7a52defb95aedb67c removed this treatment for stdin/out/err to work around a gcc 3.x bug, and since they don't actually need it (because taking their addresses is not valid C). instead, a check for the gcc 3.x bug is added to the configure check for vis.h preinclude support; this feature will simply be disabled when using a buggy version of gcc.
* try to suppress linking libc.so if there are undefined symbolsRich Felker2015-09-221-0/+6
| | | | | | | | | | this is always an error and usually results from failure to find/link the compiler runtime library, but it could also result from implementation errors in libc, using functions that don't (yet) exist. either way the resulting libc.so will crash mysteriously at runtime. the crash happens too early to produce a meaningful error, so these crashes are very confusing to users and waste a lot of debugging time. this commit should ensure that they do not happen.
* remove configure's suppression of enable sh/fdpic shared library buildRich Felker2015-09-221-1/+0
|
* add sh fdpic subarch variantsRich Felker2015-09-121-0/+4
| | | | | | | | | with this commit it should be possible to produce a working static-linked fdpic libc and application binaries for sh. the changes in reloc.h are largely unused at this point since dynamic linking is not supported, but the CRTJMP macro is used one place outside of dynamic linking, in __unmapself.
* Build process uses script to add CFI directives to x86 asmAlex Dowad2015-08-261-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some functions implemented in asm need to use EBP for purposes other than acting as a frame pointer. (Notably, it is used for the 6th argument to syscalls with 6 arguments.) Without frame pointers, GDB can only show backtraces if it gets CFI information from a .debug_frame or .eh_frame ELF section. Rather than littering our asm with ugly .cfi directives, use an awk script to insert them in the right places during the build process, so GDB can keep track of where the current stack frame is relative to the stack pointer. This means GDB can produce beautiful stack traces at any given point when single-stepping through asm functions. Additionally, when registers are saved on the stack and later overwritten, emit ..cfi directives so GDB will know where they were saved relative to the stack pointer. This way, when you look back up the stack from within an asm function, you can still reliably print the values of local variables in the caller. If this awk script were to understand every possible wild and crazy contortion that an asm programmer can do with the stack and registers, and always emit the exact ..cfi directives needed for GDB to know what the register values were in the preceding stack frame, it would necessarily be as complex as a full x86 emulator. That way lies madness. Hence, we assume that the stack pointer will _only_ ever be adjusted using push/pop or else add/sub with a constant. We do not attempt to detect every possible way that a register value could be saved for later use, just the simple and common ways. Thanks to Szabolcs Nagy for suggesting numerous improvements to this code.
* add musl-clang, a wrapper for system clang installsShiz2015-07-061-1/+12
| | | | | | | | | | | | | | musl-clang allows the user to compile musl-powered programs using their already existent clang install, without the need of a special cross compiler. it achieves this by wrapping around both the system clang install and the linker and passing them special flags to re-target musl at runtime. it does only affect invocations done through the special musl-clang wrapper script, so that the user setup remains fully intact otherwise. the clang wrapper consists of the compiler frontend wrapper script, musl-clang, and the linker wrapper script, ld.musl-clang. musl-clang makes sure clang invokes ld.musl-clang to link objects; neither script needs to be in PATH for the wrapper to work.
* build: fix musl-targeting toolchain testShiz2015-07-061-9/+8
| | | | | | | | | | | | | | | the old test was broken in that it would never fail on a toolchains built without dynamic linking support, leading to the wrapper script possibly being installed on compilers that do not support it. in addition, the new test is portable across compilers: the old test only worked on GCC. the new test works by testing whether the toolchain libc defines __GLIBC__: most non-musl Linux libc's do define this for compatibility even when they are not glibc, so this is a safe bet to check for musl. in addition, the compiler runtime would need to have a somewhat glibc-compatible ABI in the first place, so any non-glibc compatible libc's compiler runtime might not work. it is safer to disable these cases by default and have the user enable the wrappers manually there using --enable-wrapper if they certain it works.
* build: overhaul wrapper script system for multiple wrapper supportShiz2015-07-061-20/+36
| | | | | | | | | | | | | | | this overhauls part of the build system in order to support multiple toolchain wrapper scripts, as opposed to solely the musl-gcc wrapper as before. it thereby replaces --enable-gcc-wrapper with --enable-wrapper=..., which has the options 'auto' (the default, detect whether to use wrappers), 'all' (build and install all wrappers), 'no' (don't build any) and finally the options named after the individual compiler scripts (currently only 'gcc' is available) to build and install only that wrapper. the old --enable-gcc-wrapper is removed from --help, but still available. it also modifies the wrappers to use the C compiler specified to the build system as 'inner' compiler, when applicable. as wrapper detection works by probing this compiler, it may not work with any other.
* configure: work around compilers that merely warn for unknown optionsShiz2015-05-281-2/+12
| | | | | | | | | | | some compilers (such as clang) accept unknown options without error, but then print warnings on each invocation, cluttering the build output and burying meaningful warnings. this patch makes configure's tryflag and tryldflag functions use additional options to turn the unknown-option warnings into errors, if available, but only at check time. these options are not output in config.mak to avoid the risk of spurious build breakage; if they work, they will have already done their job at configure time.
* fix syntax errors in configure scriptRich Felker2015-04-221-2/+2
|
* make configure check for visibility preinclude compatible with pccRich Felker2015-04-221-3/+3
| | | | | | | | | | | | | pcc does not search for -include relative to the working directory unless -I. is used. rather than adding -I., which could be problematic if there's extra junk in the top-level directory, switch back to the old method (reverting commit 60ed988fd6c67b489d7cc186ecaa9db4e5c25b8c) of using -include vis.h and relying on -I./src/internal being present on the command line (which the Makefile guarantees). to fix the breakage that was present in trycppif checks with the old method, $CFLAGS_AUTO is removed from the command line passed to trycppif; this is valid since $CFLAGS_AUTO should not contain options that alter compiler semantics or ABI, only optimizations, warnings, etc.
* configure: check for -march and -mtune passed via CCAndre McCurdy2015-04-211-2/+4
| | | | | | | | Some build environments pass -march and -mtune as part of CC, therefore update configure to check both CC and CFLAGS before making the decision to fall back to generic -march and -mtune options for x86. Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
* fix regression in configure script with new visibility optionRich Felker2015-04-201-3/+3
| | | | | | | | | commit de2b67f8d41e08caa56bf6540277f6561edb647f introduced a regression by adding a -include option to CFLAGS_AUTO which did not work without additional -I options. this broke subsequent trycppif tests and caused x86_64 to be misdetected as x32, among other issues. simply using the full relative pathname to vis.h rather than -I is the cleanest way to fix the problem.
* add optional global visibility overrideRich Felker2015-04-191-1/+30
| | | | | | | | | | | | this is implemented via the build system and does not affect source files. the idea is to use protected or hidden visibility to prevent the compiler from pessimizing function calls within a shared (or position-independent static) libc in the form of overhead setting up for a call through the PLT. the ld-time symbol binding via the -Bsymbolic-functions option already optimized out the PLT itself, but not the code in the caller needed to support a call through the PLT. on some archs this overhead can be substantial; on others it's trivial.
* allow libc itself to be built with stack protector enabledRich Felker2015-04-131-1/+9
| | | | | | | | | | | | | | | | | | | | this was already essentially possible as a result of the previous commits changing the dynamic linker/thread pointer bootstrap process. this commit mainly adds build system infrastructure: configure no longer attempts to disable stack protector. instead it simply determines how so the makefile can disable stack protector for a few translation units used during early startup. stack protector is also disabled for memcpy and memset since compilers (incorrectly) generate calls to them on some archs to implement struct initialization and assignment, and such calls may creep into early initialization. no explicit attempt to enable stack protector is made by configure at this time; any stack protector option supported by the compiler can be passed to configure in CFLAGS, and if the compiler uses stack protector by default, this default is respected.