Controlling what the GNU linker exports from a shared library would
authorNicholas Clark <nick@ccl4.org>
Sun, 18 Sep 2005 10:12:51 +0000 (10:12 +0000)
committerNicholas Clark <nick@ccl4.org>
Sun, 18 Sep 2005 10:12:51 +0000 (10:12 +0000)
be a useful thing TODO

p4raw-id: //depot/perl@25459

pod/perltodo.pod

index 07361a3..4d13b68 100644 (file)
@@ -245,6 +245,18 @@ that this is due to incomplete dependency specification in the F<Makefile>.
 It would be good if someone were able to track down the causes of these
 problems, so that parallel builds worked properly.
 
+=head2 linker specification files
+
+Some platforms mandate that you provide a list of a shared library's external
+symbols to the linker, so the core already has the infrastructure in place to
+do this for generating shared perl libraries. My understanding is that the
+GNU toolchain can accept an optional linker specification file, and restrict
+visibility just to symbols declared in that file. It would be good to extend
+F<makedef.pl> to support this format, and to provide a means within
+C<Configure> to enable it. This would allow Unix users to test that the
+export list is correct, and to build a perl that does not pollute the global
+namespace with private symbols.
+