diff options
author | Rich Felker <dalias@aerifal.cx> | 2013-07-01 13:43:43 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2013-07-01 13:43:43 -0400 |
commit | d66ab4f1409ad1a2093239ef48b7bca596acdf52 (patch) | |
tree | b712451efc30a3a751936a37db14b675d9374416 /src/signal/x86_64 | |
parent | 6688a778b0419eab32e715f269319248edee9da5 (diff) | |
download | musl-d66ab4f1409ad1a2093239ef48b7bca596acdf52.tar.gz musl-d66ab4f1409ad1a2093239ef48b7bca596acdf52.tar.xz musl-d66ab4f1409ad1a2093239ef48b7bca596acdf52.zip |
fix Makefile so "make install" works before include/bits symlink exists
previously, determination of the list of header files for installation depended on the include/bits symlink (to the arch-specific files) already having been created. in other words, running "make install" immediately after configure without first running "make" caused the bits headers not to be installed. the solution I have applied is to pull the list of headers directly from arch/$(ARCH)/bits rather than include/bits, and likewise to install directly from arch/$(ARCH)/bits rather than via the symlink. at this point, the only purpose served by keeping the symlink around is that it enables use of the in-tree headers and libs directly via -I and -L, which can be useful when testing against a new version of the library before installing it. on the other hand, removing the bits symlink would be beneficial if we ever want to support building multiple archs in the same source tree.
Diffstat (limited to 'src/signal/x86_64')
0 files changed, 0 insertions, 0 deletions