> Some ports want to aggregate these into shared objects...
> this tends to fail.
>
> Any negative side-effect ?
I think this is a really bad idea. You're going to end up with multiple
copies of the code and you'll
never be quite sure what copy ends up being used. Especially dangerous
for dlopen()'ed stuff.
Turn it into a proper shared library instead.
> Index: libl/Makefile
> ===================================================================
> RCS file: /cvs/src/lib/libl/Makefile,v
> retrieving revision 1.4
> diff -u -p -r1.4 Makefile
> --- libl/Makefile 24 Nov 2005 20:49:18 -0000 1.4
> +++ libl/Makefile 19 Jun 2012 09:39:47 -0000
> @@ -5,6 +5,7 @@ LIB= l
> WANTLINT=
> SRCS= libmain.c libyywrap.c
> NOPIC=
> +CFLAGS += ${PICFLAG}
>
> .PATH: ${.CURDIR}/../../usr.bin/lex
>
> Index: libarch/amd64/Makefile
> ===================================================================
> RCS file: /cvs/src/lib/libarch/amd64/Makefile,v
> retrieving revision 1.10
> diff -u -p -r1.10 Makefile
> --- libarch/amd64/Makefile 13 Apr 2011 02:49:12 -0000 1.10
> +++ libarch/amd64/Makefile 19 Jun 2012 09:39:47 -0000
> @@ -10,6 +10,7 @@ MLINKS+=amd64_get_ioperm.2 amd64_set_iop
> .if ${MACHINE_ARCH} == "amd64"
> .PATH: ${LIBC}/amd64
> NOPIC=
> +CFLAGS += ${PICFLAG}
> SRCS+= amd64_iopl.c amd64_get_ioperm.c amd64_set_ioperm.c \
> amd64_get_fsbase.c amd64_set_fsbase.c
> .include <bsd.lib.mk>
