From: <dan...@ya...> - 2002-03-08 03:25:51
|
--- "Timothy J. Wood" <tj...@om...> wrote: > > On Thursday, March 7, 2002, at 03:34 PM, Danny Smith wrote: > > I have built libobjc.dll for 3.1 and have modified headers with > > dllimport > > macros (as per gnustep sources) but have only tested it with the > > gcc-3.1 > > testsuite. Let me rephrase earlier question. > > This needs to get committed to the FSF repository (whatever the final > version is) rather than having to grab anything from gnustep. I assume > you are waiting until the answers to the following become apparent, but > I just want to suggest that FSF/GCC should really be where all of the > GCC MinGW bits live. > I agree completely. Go for it. The only thing I changed in my local GCC tree was to add the objc_EXPORT macros to the headers and updated the .def file to make sure that all the exports were there. Then just do a make liboobjc.dll. I was planning to submit patches to that effect on the road to 3.2, but it is not high priority for me. > > Should libobjc.dll.a (my choice for naming of the dll implib, to keep > > consistent with the way binutils looks for libs) precede static > > libobjc.a > > in search order (as it would now by default, following ld precedence > > rules > > ). If so the dllimport macros in headers need to be turned on by > > default > > > > Should I, instead, use the libobjc_s.a/libobjc.a names for static lib > > and > > shared lib respectively as per GCC makefile. If so which should be > > default? > > Ugh. I don't think there is a perfect answer here. Inevitably some > people will want shared and some people will want static. > > I think it is reasonable to have shared be the default if > --enable-shared was specified when GCC was built (since that seem to be > the way every other shared library linker works), but making sure that > headers get declspec'ed correctly will be ugly. > At present --enable-shared doesn't do anything for w32 targets. It won't until someonr makes it do something. GCC still uses an older version of libtool. Newer versions of libtool have better support for building dll's but they need to use --auto-import. There are still some problems with --auto-import. > > > The builtin objc specs probably need to be modified so that if shared > > lib, > > define the dllimport macros, else don't. > > How will you figure out at compile time whether the shared library > will get used? Would you check for the presence of the dll implib > (problematic since you don't necessary have all the -L switches)? > > If you require a -DOBJC_SHARED flag then anyone that indirectly > includes ObjC headers will also need to build with this define (i.e., > they are using a DLL that exports and ObjC API that itself links against > the ObjC runtime DLL). This is really ugly. One away to do it (this is similar to how Paul Sokolovsky did it with his shared version of libstdc++) is to incorporate soemthing like this in specs: Change this: %{static:-Bstatic} %{!static:-Bdynamic} to %{static:-Bstatic -D__ALL_STATIC__} %{!static:-Bdynamic} Which would make libfoo.dll.a take precendence over libfoo.a by default (as it does now) when ld sees -lfoo but would define __ALL_STATIC__ for preprocessor and make libfoo.a have priority over libfoo.dll.a whenever the -static flag is passed to GCC. The latter precendence rule would be overriden if we replace -lfoo with explicit -lfoo.dll . Then the dllimport macros in runtime headers could be conditional on __ALL_STATIC__ > > Probably the most robust solution would be to have configure flags > '--objc-enable-shared' and '--objc-enable-static', make them exclusive > of each other (at least on Win32) and then munge the header when the > runtime is built to be hard coded one way or the other. Then there is > less chance of getting your wires crossed when building multiple layers > of packages (and no -D flags required). > > Another robust (but ugly and incompatible) solution would be to > install two copies of the objc runtime headers, objc-shared and > objc-static and rename the symbols in such a way that if you import one > copy of the headers you will fail to link unless you link the right > library. Cringe. > Okay, you've convinced me. I will only put static libs in binary distro for now. When you or I or someone else comes up with an acceptable patch to FSF sources, than anyone can change to using dll's if they want to. We are going to run into the same types of problems -- but much bigger --when people start asking for libstdc++.dll. > -tim > > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users http://movies.yahoo.com.au - Yahoo! Movies - Vote for your nominees in our online Oscars pool. |