about summary refs log tree commit diff
path: root/tools/musl-gcc.specs.sh
Commit message (Collapse)AuthorAgeFilesLines
* fix musl-gcc wrapper to be compatible with default-pie gcc toolchainsRich Felker2018-08-021-2/+2
| | | | | | | | | | | the specfile for the wrapper was written assuming output is pie only if -pie appears on the command line. recent (and older patched) versions of gcc can be configured to produce pie output by default, adn when used with such a toolchain, the wrapper linked the wrong startfiles (crt*) containing pic-incompatible code. rather than trying to figure out gcc's default, simply always use the pic-compatible start files.
* fix mixup in previous change to gcc wrapperRich Felker2013-06-071-1/+1
|
* make gcc-specific headers (intrinsics, etc.) available with wrapperRich Felker2013-06-071-2/+2
| | | | | they are intentionally listed after the libc include directory so that the gcc float.h, etc. don't get used in place of the libc ones.
* gcc wrapper improvement: leave libgcc dir in the library pathRich Felker2012-07-231-1/+1
| | | | | this is needed in case -lgcc is passed explicitly on the link command line, for example if the wrapper is being used to build musl itself.
* make gcc wrapper rewrite link options rather than just extending themRich Felker2012-06-061-3/+1
| | | | | this is not tested yet, but should work to get rid of unwanted --hash-style=gnu hacks present in some distro-patched gcc versions.
* fix musl-gcc wrapper to work with -pieRich Felker2012-05-301-1/+1
| | | | linking the wrong crt1.o resulted in textrels and thus crashing
* new gcc wrapper, entirely specfile basedRich Felker2012-04-221-0/+39
the _concept_ of this wrapper has been tested extensively, but the integration with the build/install system, and using a persistent specfile rather than one generated at build-time, have not been heavily tested and may need minor tweaks. this approach should be a lot more robust (and easier to improve) than writing a shell script that's responsible for trying to mimic gcc's logic about whether it's compiling or linking, building shared libs or executable files, etc. it's also lighter weight and should result in mildly faster builds when using the wrapper.