search for: 326c326

...(like, say, a new pass) correctly on OS X - they were being built as shared libraries and not bundles, so they couldn't be loaded with dlopen. The discussion is in the archives if you want more details... I fixed it locally by doing the following hack: % diff Makefile.rules.old Makefile.rules 326c326 < Link := $(LIBTOOL) --mode=link $(CXX) --- > Link := $(LIBTOOL) --mode=link $(CXX) -module (Note that libtool on OS X is not quite gnu libtool) If there's a saner way to incorporate this fix, now might be the time, since you're working on it already. Hope this isn't pi...

...u don't need to change DynamicLinker.cpp at all. dlopen() should just work, except that the defaults for libtool are to produce the wrong kind of shared object. On OS X, libtool needs to be passed the -module option to create dlopen-able objects: % diff Makefile.rules.old Makefile.rules 326c326 < Link := $(LIBTOOL) --mode=link $(CXX) --- > Link := $(LIBTOOL) --mode=link $(CXX) -module This hack isn't a complete fix, because SHLIBEXT is still set wrong. (It should be .so not .dylib). I couldn't figure out how to do that right, so I didn't try and it didn'...

Hello, I've closed PR106 (use automake) as WONTFIX. I've already delineated the problems with automake in previous posts but as of now, all the automake related stuff has been removed from the repository. In an effort to start making our makefile system better, I've committed changes to Makefile.rules and a few library Makefiles that nearly double the speed of our compilations. I

OK, seems like I've got some more looking to do. From what I can find, the only difference with OS X and dynamic libraries is that you can't depend on the order of calling static constructors, but not that you can't depend on them getting called. :) If I find that library handling in LLVM needs changes to work with OS X, I'll send a patch. Thanks, -mike On Jun 19, 2004,