Bugzilla – Bug 214
hard-wired assumption that shared-library extension is ".so"
Last modified: 2004-01-26 15:29:30
You need to log in before you can comment on or make changes to this bug.
On MacOSX shared libraries end in ".dylib". Some parts of the LLVM build system (configure, mklib) seem to know this, but not all (Makefile.rules). As a result, "make install" always fails (in install-dynamic-library). I have attached a patch below. (Undoubtedly this is not the best patch, but it is a satisfactory workaround.) There may also be other places where ".so" is hard-wired (e.g. gccld/Linker.cpp). [hatter:~/Work/llvm/llvm] % cvs diff Index: Makefile.rules =============================================================== ==== RCS file: /var/cvs/llvm/llvm/Makefile.rules,v retrieving revision 1.169 diff -B -u -b -r1.169 Makefile.rules --- Makefile.rules 16 Jan 2004 21:31:20 -0000 1.169 +++ Makefile.rules 20 Jan 2004 23:22:58 -0000 @@ -107,9 +107,13 @@ # used by this Makefile, and cancel useless implicit rules. This # will hopefully speed up compilation a little bit. ########################################################################### +so := so +ifeq ($(OS),Darwin) +so := dylib +endif .SUFFIXES: .SUFFIXES: .c .cpp .h .hpp .y .l -.SUFFIXES: .lo .o .a .so .bc .td +.SUFFIXES: .lo .o .a .$(so) .bc .td .SUFFIXES: .ps .dot .d # @@ -459,10 +463,10 @@ # Make sure there isn't any extranous whitespace on the LIBRARYNAME option LIBRARYNAME := $(strip $(LIBRARYNAME)) -LIBNAME_O := $(DESTLIBRELEASE)/lib$(LIBRARYNAME).so -LIBNAME_P := $(DESTLIBPROFILE)/lib$(LIBRARYNAME).so -LIBNAME_G := $(DESTLIBDEBUG)/lib$(LIBRARYNAME).so -LIBNAME_CUR := $(DESTLIBCURRENT)/lib$(LIBRARYNAME).so +LIBNAME_O := $(DESTLIBRELEASE)/lib$(LIBRARYNAME).$(so) +LIBNAME_P := $(DESTLIBPROFILE)/lib$(LIBRARYNAME).$(so) +LIBNAME_G := $(DESTLIBDEBUG)/lib$(LIBRARYNAME).$(so) +LIBNAME_CUR := $(DESTLIBCURRENT)/lib$(LIBRARYNAME).$(so) LIBNAME_AO := $(DESTLIBRELEASE)/lib$(LIBRARYNAME).a LIBNAME_AP := $(DESTLIBPROFILE)/lib$(LIBRARYNAME).a LIBNAME_AG := $(DESTLIBDEBUG)/lib$(LIBRARYNAME).a @@ -544,7 +548,7 @@ install-dynamic-library: $(LIBNAME_CUR) $(MKDIR) $(libdir) - $(VERB) $(LIBTOOL) --mode=install $(INSTALL) $(LIBNAME_CUR) $(libdir)/lib$(LIBRARYNAME).so + $(VERB) $(LIBTOOL) --mode=install $(INSTALL) $(LIBNAME_CUR) $(libdir)/ lib$(LIBRARYNAME).$(so) # # Rules for building static archive libraries. @@ -813,7 +817,7 @@ $(VERB) $(RM) -rf $(BUILD_OBJ_DIR)/Debug $(BUILD_OBJ_DIR)/Release $(VERB) $(RM) -rf $(BUILD_OBJ_DIR)/Profile $(BUILD_OBJ_DIR)/Depend $(VERB) $(RM) -rf $(BUILD_OBJ_DIR)/BytecodeObj - $(VERB) $(RM) -f core core.[0-9][0-9]* *.o *.d *.so *~ *.flc + $(VERB) $(RM) -f core core.[0-9][0-9]* *.o *.d *.$(so) *~ *.flc $(VERB) $(RM) -f $(LEX_OUTPUT) $(YACC_OUTPUT) ###########################################################################
on it
This also affects lib/Support/ToolRunner.cpp, tools/gccld/Linker.cpp, and there are many places in the docs and --help output where ".so" is mentioned.
I applied a modified version of your patch (with some autoconf hooks instead of the ifeq ($(OS),Darwin)...endif). Thanks for sending it. My one request is that you please use 'Create a New Attachment' to submit patches next time, b/c if you just paste them in the 'Additional Comments' text area, they get screwed up by the word-wrap. http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040119/010891.html http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040119/010892.html http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040119/010893.html http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040119/010894.html http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040119/010895.html
also: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040119/010896.html I'll have a look at the rest of the places where I found .so hardcoded, later today.
Unfortunately, I'm not going to have time to fix this the rest of the way right now, at least until next week. ----> criswell for help.
Also, PluginLoader.cpp and the release notes will need to be updated, but there are pretty cosmetic. :) -Chris
I believe I've got everything in LLVM proper fixed, and I've updated the release notes for the next release. Documentation has also been updated.