Darwin option processing

I'm toying with building with -mdynamic-no-pic, but for this to work, the shared library bits in llvm can't be built with that flag.

I've found that:

Index: Makefile.rules

I'm toying with building with -mdynamic-no-pic, but for this to work,
the shared library bits in llvm can't be built with that flag.

Hi Mike,

If you're doing this for Clang's benefit, I think the best thing to do is to compile LLVM PIC (the default) and then build the clang front-end pieces with -mdynamic-no-pic. Does this work for you?

-Chris

I'm toying with building with -mdynamic-no-pic, but for this to work,
the shared library bits in llvm can't be built with that flag.

Hi Mike,

If you're doing this for Clang's benefit,

No, not really, I'm doing it for the general benefit of llvm and all that use Makefile.rules.

I think the best thing to do
is to compile LLVM PIC (the default) and then build the clang front-
end pieces with -mdynamic-no-pic. Does this work for you?

The proposed patch is more general that that. It avoids the flag, when it is known it can't work, and leaves it in otherwise. This allows the configurer of llvm to make the choice. Longer term, I'd like to have the build system default to this, as appropriate. This patch is merely a bridge until that patch is in. If you'd prefer that patch instead, I could just do that one up. My only reservation is that a change like that precedes the testing I'd rather have on it before I did the flip.

The other patch would look something like this:

Index: Makefile.rules

I think the best thing to do
is to compile LLVM PIC (the default) and then build the clang front-
end pieces with -mdynamic-no-pic. Does this work for you?

The proposed patch is more general that that. It avoids the flag,
when it is known it can't work, and leaves it in otherwise. This
allows the configurer of llvm to make the choice. Longer term, I'd
like to have the build system default to this, as appropriate. This
patch is merely a bridge until that patch is in. If you'd prefer that
patch instead, I could just do that one up. My only reservation is
that a change like that precedes the testing I'd rather have on it
before I did the flip.

This goes against our general direction for llvm libraries: they should generally all be built pic. This is because we don't know how they will be linked in. For example, anything that links into liblto or llvm-gcc (on the mac) get stuck into dylibs.

The other patch would look something like this:

Index: Makefile.rules

--- Makefile.rules (revision 71041)
+++ Makefile.rules (working copy)
@@ -245,6 +245,13 @@
     OmitFramePointer := -fomit-frame-pointer
   endif
+ ifndef LOADABLE_MODULE
+ ifndef SHARED_LIBRARY
+ ifeq ($(OS),Darwin)
+ DynamicNoPic := -mdynamic-no-pic
+ endif
+ endif
+ endif

How about factoring the logic so that there is one PIC_SETTING. This setting can be either -fpic, -mdynamic-no-pic, or empty.

-Chris

This goes against our general direction for llvm libraries: they should generally all be built pic.

After reviewing yet more of the Makefile,rules file, I believe ENABLE_PIC is the right thing to check. Currently ENABLE_PIC has to be set to get shared bits built, if the user wants them. Given that, we can use that to control wether or not -mdynamic-no-pic is added. Because this _must_ be set, it is safe to use the setting of that flag to make the decision on wether to add -mdynamic-no-pic. If that flag isn't set, the resulting objects, in general, can't be used in a shared library.

This is because we don't know how they will be linked in.

Currently, the Makefile does know how the object will be used. On darwin, -fno-common is only added when ENABLE_PIC is 1, and objects can't be used in a shared library unless -fno-common is added.

Index: clang/Makefile.rules

This goes against our general direction for llvm libraries: they
should generally all be built pic.

After reviewing yet more of the Makefile,rules file, I believe
ENABLE_PIC is the right thing to check.

Looks good to me, thanks Mike.

-Chris