d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
ae94017be3
freebsd-skq/lib/libc_nonshared/Makefile

29 lines
656 B
Makefile
Raw Normal View History

Attempt to move the POSIX iconv* symbols out of runtime linker space. FreeBSD systems usually implemented this as a third party module and our implementation hasn't played as nicely with the old way as it could have. To that end: * Rename the iconv* symbols in libc.so.7 to have a __bsd_ prefix. * Provide .symver compatability with existing 10.x+ binaries that referenced the iconv symbols. All existing binaries should work. * Like on Linux/glibc systems, add a libc_nonshared.a to the ldscript at /usr/lib/libc.so. * Move the "iconv*" wrapper symbols to libc_nonshared.a This should solve the runtime ambiguity about which symbols resolve to where. If you compile against the iconv in libc, your runtime dependencies will be unambiguous. Old 9.x libraries and binaries will always resolve against their libiconv.so.3 like they did on 9.x. They won't resolve against libc. Old 10.x binaries will be satisified by the .symver helpers. This should allow ports to selectively compile against the libiconv port if needed and it should behave without ambiguity now. Discussed with: kib
2013-11-17 22:52:17 +00:00
# $FreeBSD$
# We're actually creating a libc_noshared.a that is PIC along side libc.so.*
# It is used exclusively with libc.so.* - there is no need for any other
# compile modes.
# bsd.lib.mk doesn't have an easy way to express that.
Spell NO_PROFILE= as MK_PROFILE=no.
2014-04-25 19:25:26 +00:00
MK_PROFILE?=no
Use src.opts.mk in preference to bsd.own.mk except where we need stuff from the latter.
2014-05-06 04:22:01 +00:00
.include <src.opts.mk>
Attempt to move the POSIX iconv* symbols out of runtime linker space. FreeBSD systems usually implemented this as a third party module and our implementation hasn't played as nicely with the old way as it could have. To that end: * Rename the iconv* symbols in libc.so.7 to have a __bsd_ prefix. * Provide .symver compatability with existing 10.x+ binaries that referenced the iconv symbols. All existing binaries should work. * Like on Linux/glibc systems, add a libc_nonshared.a to the ldscript at /usr/lib/libc.so. * Move the "iconv*" wrapper symbols to libc_nonshared.a This should solve the runtime ambiguity about which symbols resolve to where. If you compile against the iconv in libc, your runtime dependencies will be unambiguous. Old 9.x libraries and binaries will always resolve against their libiconv.so.3 like they did on 9.x. They won't resolve against libc. Old 10.x binaries will be satisified by the .symver helpers. This should allow ports to selectively compile against the libiconv port if needed and it should behave without ambiguity now. Discussed with: kib
2013-11-17 22:52:17 +00:00
NO_PIC=
# -fpic on some platforms, -fPIC on others.
CFLAGS+=${PICFLAG} -DPIC -fvisibility=hidden
LIB= c_nonshared
Move the iconv wrapper source from libc_nonshared to libc/iconv so that it is all in the one place again. Rename libc/iconv/iconv.c to bsd_iconv.c. Compile the wrappers into libc.a so that WITHOUT_DYNAMICROOT works again. Discussed with: kib (and partly stolen from his patch)
2013-11-25 20:17:55 +00:00
LIBC_NONSHARED_SRCS=
Attempt to move the POSIX iconv* symbols out of runtime linker space. FreeBSD systems usually implemented this as a third party module and our implementation hasn't played as nicely with the old way as it could have. To that end: * Rename the iconv* symbols in libc.so.7 to have a __bsd_ prefix. * Provide .symver compatability with existing 10.x+ binaries that referenced the iconv symbols. All existing binaries should work. * Like on Linux/glibc systems, add a libc_nonshared.a to the ldscript at /usr/lib/libc.so. * Move the "iconv*" wrapper symbols to libc_nonshared.a This should solve the runtime ambiguity about which symbols resolve to where. If you compile against the iconv in libc, your runtime dependencies will be unambiguous. Old 9.x libraries and binaries will always resolve against their libiconv.so.3 like they did on 9.x. They won't resolve against libc. Old 10.x binaries will be satisified by the .symver helpers. This should allow ports to selectively compile against the libiconv port if needed and it should behave without ambiguity now. Discussed with: kib
2013-11-17 22:52:17 +00:00
# So that an empty .a file doesn't cause errors.
SRCS= __stub.c
.if ${MK_ICONV} == "yes"
Move the iconv wrapper source from libc_nonshared to libc/iconv so that it is all in the one place again. Rename libc/iconv/iconv.c to bsd_iconv.c. Compile the wrappers into libc.a so that WITHOUT_DYNAMICROOT works again. Discussed with: kib (and partly stolen from his patch)
2013-11-25 20:17:55 +00:00
.PATH: ${.CURDIR}/../libc/iconv
.include "Makefile.iconv"
Attempt to move the POSIX iconv* symbols out of runtime linker space. FreeBSD systems usually implemented this as a third party module and our implementation hasn't played as nicely with the old way as it could have. To that end: * Rename the iconv* symbols in libc.so.7 to have a __bsd_ prefix. * Provide .symver compatability with existing 10.x+ binaries that referenced the iconv symbols. All existing binaries should work. * Like on Linux/glibc systems, add a libc_nonshared.a to the ldscript at /usr/lib/libc.so. * Move the "iconv*" wrapper symbols to libc_nonshared.a This should solve the runtime ambiguity about which symbols resolve to where. If you compile against the iconv in libc, your runtime dependencies will be unambiguous. Old 9.x libraries and binaries will always resolve against their libiconv.so.3 like they did on 9.x. They won't resolve against libc. Old 10.x binaries will be satisified by the .symver helpers. This should allow ports to selectively compile against the libiconv port if needed and it should behave without ambiguity now. Discussed with: kib
2013-11-17 22:52:17 +00:00
CFLAGS+=-I${.CURDIR}/../libc/iconv
.endif
Move the iconv wrapper source from libc_nonshared to libc/iconv so that it is all in the one place again. Rename libc/iconv/iconv.c to bsd_iconv.c. Compile the wrappers into libc.a so that WITHOUT_DYNAMICROOT works again. Discussed with: kib (and partly stolen from his patch)
2013-11-25 20:17:55 +00:00
SRCS+= ${LIBC_NONSHARED_SRCS}
Attempt to move the POSIX iconv* symbols out of runtime linker space. FreeBSD systems usually implemented this as a third party module and our implementation hasn't played as nicely with the old way as it could have. To that end: * Rename the iconv* symbols in libc.so.7 to have a __bsd_ prefix. * Provide .symver compatability with existing 10.x+ binaries that referenced the iconv symbols. All existing binaries should work. * Like on Linux/glibc systems, add a libc_nonshared.a to the ldscript at /usr/lib/libc.so. * Move the "iconv*" wrapper symbols to libc_nonshared.a This should solve the runtime ambiguity about which symbols resolve to where. If you compile against the iconv in libc, your runtime dependencies will be unambiguous. Old 9.x libraries and binaries will always resolve against their libiconv.so.3 like they did on 9.x. They won't resolve against libc. Old 10.x binaries will be satisified by the .symver helpers. This should allow ports to selectively compile against the libiconv port if needed and it should behave without ambiguity now. Discussed with: kib
2013-11-17 22:52:17 +00:00
Move the iconv wrapper source from libc_nonshared to libc/iconv so that it is all in the one place again. Rename libc/iconv/iconv.c to bsd_iconv.c. Compile the wrappers into libc.a so that WITHOUT_DYNAMICROOT works again. Discussed with: kib (and partly stolen from his patch)
2013-11-25 20:17:55 +00:00
.include <bsd.lib.mk>
Reference in New Issue Copy Permalink