* [3.2/3.3/HEAD] shared libobjc not built @ 2003-01-01 15:52 Matthias Klose 2003-01-02 15:31 ` Andrea 'fwyzard' Bocci 0 siblings, 1 reply; 13+ messages in thread From: Matthias Klose @ 2003-01-01 15:52 UTC (permalink / raw) To: gcc gcc configured without explicit --enabled-shared builds shared libraries for libstdc++, libgcj, etc, but not for libobjc (i386-linux) Is this intended? libobjc's configure sets the default to disabled. [...] checking whether the linker (ld) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so checking command to parse nm output... ok checking if libtool supports shared libraries... yes checking whether to build shared libraries... no checking whether to build static libraries... yes creating libtool updating cache ../config.cache loading cache ../config.cache [...] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [3.2/3.3/HEAD] shared libobjc not built 2003-01-01 15:52 [3.2/3.3/HEAD] shared libobjc not built Matthias Klose @ 2003-01-02 15:31 ` Andrea 'fwyzard' Bocci 2003-01-02 15:48 ` Nicola Pero [not found] ` <Pine.LNX.4.21.0301021543470.3304-100000@nicola.brainstorm. co.uk> 0 siblings, 2 replies; 13+ messages in thread From: Andrea 'fwyzard' Bocci @ 2003-01-02 15:31 UTC (permalink / raw) To: Matthias Klose; +Cc: gcc At 16.47 01/01/2003 +0100, Matthias Klose wrote: >gcc configured without explicit --enabled-shared builds shared >libraries for libstdc++, libgcj, etc, but not for libobjc (i386-linux) >Is this intended? libobjc's configure sets the default to disabled. From <http://gcc.gnu.org/install/configure.html>: >--enable-shared[=package[,...]] >Build shared versions of libraries, if shared libraries are supported on >the target platform. Unlike GCC 2.95.x and earlier, shared libraries are >enabled by default on all platforms that support shared libraries, except >for libobjc which is built as a static library only by default. >If a list of packages is given as an argument, build shared libraries only >for the listed packages. For other packages, only static libraries will be >built. Package names currently recognized in the GCC tree are libgcc (also >known as gcc), libstdc++ (not libstdc++-v3), libffi, zlib, boehm-gc and >libjava. Note that libobjc does not recognize itself by any name, so, if >you list package names in --enable-shared, you will only get static >Objective-C libraries. libf2c and libiberty do not support shared >libraries at all. So, yes, I think it's intended, but I don't know why. fwyzard ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [3.2/3.3/HEAD] shared libobjc not built 2003-01-02 15:31 ` Andrea 'fwyzard' Bocci @ 2003-01-02 15:48 ` Nicola Pero [not found] ` <Pine.LNX.4.21.0301021543470.3304-100000@nicola.brainstorm. co.uk> 1 sibling, 0 replies; 13+ messages in thread From: Nicola Pero @ 2003-01-02 15:48 UTC (permalink / raw) To: Andrea 'fwyzard' Bocci; +Cc: Matthias Klose, gcc > >gcc configured without explicit --enabled-shared builds shared > >libraries for libstdc++, libgcj, etc, but not for libobjc (i386-linux) > >Is this intended? libobjc's configure sets the default to disabled. > > From <http://gcc.gnu.org/install/configure.html>: > >--enable-shared[=package[,...]] > >Build shared versions of libraries, if shared libraries are supported on > >the target platform. Unlike GCC 2.95.x and earlier, shared libraries are > >enabled by default on all platforms that support shared libraries, except > >for libobjc which is built as a static library only by default. > >If a list of packages is given as an argument, build shared libraries only > >for the listed packages. For other packages, only static libraries will be > >built. Package names currently recognized in the GCC tree are libgcc (also > >known as gcc), libstdc++ (not libstdc++-v3), libffi, zlib, boehm-gc and > >libjava. Note that libobjc does not recognize itself by any name, so, if > >you list package names in --enable-shared, you will only get static > >Objective-C libraries. libf2c and libiberty do not support shared > >libraries at all. > > So, yes, I think it's intended, but I don't know why. I don't know either ... I don't remember - maybe a historical leftover ? I think if shared libraries are supported, libobjc should be built as shared. It should definitely be built as shared, why building it statically ? A static libobjc is usually more of a problem than a shared one! ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <Pine.LNX.4.21.0301021543470.3304-100000@nicola.brainstorm. co.uk>]
* Re: [3.2/3.3/HEAD] shared libobjc not built [not found] ` <Pine.LNX.4.21.0301021543470.3304-100000@nicola.brainstorm. co.uk> @ 2003-01-02 16:06 ` Andrea 'fwyzard' Bocci 2003-01-02 16:32 ` Nicola Pero 0 siblings, 1 reply; 13+ messages in thread From: Andrea 'fwyzard' Bocci @ 2003-01-02 16:06 UTC (permalink / raw) To: Nicola Pero; +Cc: Matthias Klose, gcc At 15.48 02/01/2003 +0000, Nicola Pero wrote: > > So, yes, I think it's intended, but I don't know why. > >I don't know either ... I don't remember - maybe a historical leftover ? > >I think if shared libraries are supported, libobjc should be built as >shared. It should definitely be built as shared, why building it >statically ? A static libobjc is usually more of a problem than a shared >one! I don't actually use, ObjC, so I don't really know about it But I always build with --enable-shared, just to be sure :-) Maybe some Knowledgeable Person here can aswer that... fwyzard ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [3.2/3.3/HEAD] shared libobjc not built 2003-01-02 16:06 ` Andrea 'fwyzard' Bocci @ 2003-01-02 16:32 ` Nicola Pero 2003-01-02 20:54 ` Timothy J. Wood 0 siblings, 1 reply; 13+ messages in thread From: Nicola Pero @ 2003-01-02 16:32 UTC (permalink / raw) To: Andrea 'fwyzard' Bocci; +Cc: Matthias Klose, gcc > > > So, yes, I think it's intended, but I don't know why. > > > >I don't know either ... I don't remember - maybe a historical leftover ? > > > >I think if shared libraries are supported, libobjc should be built as > >shared. It should definitely be built as shared, why building it > >statically ? A static libobjc is usually more of a problem than a shared > >one! > > I don't actually use, ObjC, so I don't really know about it But I always > build with --enable-shared, just to be sure :-) > Maybe some Knowledgeable Person here can aswer that... Hmmm ... I suspected to have originally wrote/submitted the lines # Disable shared libs by default AC_DISABLE_SHARED of libobjc/configure.in myself; now checking the CVS and ChangeLog entries confirmed it. I don't remember any reason why I wanted to disable shared libs, and I think that the reason of disabling shared libs by default was just that, being the switch to build libobjc as shared an experimental change to libobjc at the time, I was being conservative. Since we have tested this a lot now (more than two years of testing is enough I presume :-), I don't see any reason to keep shared libs disabled by default now, if shared libs are available on the platform. It's stupid and it just makes configuring GCC for Objective-C more troublesome. Nor do I see any reason to keep the libobjc building and configuring process different from the one used by other shared libs included in GCC. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [3.2/3.3/HEAD] shared libobjc not built 2003-01-02 16:32 ` Nicola Pero @ 2003-01-02 20:54 ` Timothy J. Wood 2003-01-03 0:01 ` Nicola Pero 0 siblings, 1 reply; 13+ messages in thread From: Timothy J. Wood @ 2003-01-02 20:54 UTC (permalink / raw) To: Nicola Pero; +Cc: Andrea 'fwyzard' Bocci, Matthias Klose, gcc On Thursday, January 2, 2003, at 08:32 AM, Nicola Pero wrote: > Hmmm ... I suspected to have originally wrote/submitted the lines > > # Disable shared libs by default > AC_DISABLE_SHARED For what it's worth, I know that there were problems building shared objc in MinGW. Maybe this came from there? (I'd sure love it if libobjc worked as a shlib on MinGW, though :) -tim ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [3.2/3.3/HEAD] shared libobjc not built 2003-01-02 20:54 ` Timothy J. Wood @ 2003-01-03 0:01 ` Nicola Pero 2003-01-03 0:46 ` Timothy J. Wood 0 siblings, 1 reply; 13+ messages in thread From: Nicola Pero @ 2003-01-03 0:01 UTC (permalink / raw) To: Timothy J. Wood; +Cc: Andrea 'fwyzard' Bocci, Matthias Klose, gcc > > Hmmm ... I suspected to have originally wrote/submitted the lines > > > > # Disable shared libs by default > > AC_DISABLE_SHARED > > > For what it's worth, I know that there were problems building shared > objc in MinGW. Maybe this came from there? > > (I'd sure love it if libobjc worked as a shlib on MinGW, though :) Thanks - 'problems building shared objc in MinGW' - do you mean it doesn't compile, or just that once you've compiled it, it's quite useless ? Because I don't use windows, but on GNUstep's instructions for MinGW I find - "It's a good idea to remove the libobjc.a and include/objc header that come with gcc (gcc -v for location) so that they are not accidentally found instead of the libobjc DLL that you will compile below." and I've heard this repeated on mailing lists quite often, so I suspect building libobjc as static on MinGW is not really a solution either, as it seems a libobjc.a on MinGW is not really a usable thing :-) [I think the problem starts when people build all other libraries as DLLs, and mixing DLLs and static libs doesn't seem a good thing ... well I don't really know, but that's what I heard]. The 'libobjc DLL that you will compile below.' is of course built from GNUstep's separate maintained version of libobjc, which can be built and used out-of-the-box as a DLL on MinGW. I suppose what we'd really want then is to fix building the libobjc shipped with GCC as a DLL on MinGW. :-) I don't have the time to work on this. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [3.2/3.3/HEAD] shared libobjc not built 2003-01-03 0:01 ` Nicola Pero @ 2003-01-03 0:46 ` Timothy J. Wood 2003-01-03 3:55 ` Nicola Pero 0 siblings, 1 reply; 13+ messages in thread From: Timothy J. Wood @ 2003-01-03 0:46 UTC (permalink / raw) To: Nicola Pero; +Cc: Andrea 'fwyzard' Bocci, Matthias Klose, gcc On Thursday, January 2, 2003, at 04:00 PM, Nicola Pero wrote: > Thanks - 'problems building shared objc in MinGW' - do you mean it > doesn't > compile, or just that once you've compiled it, it's quite useless ? My personal experience was that the MinGW distribution just wouldn't build a DLL for ObjC. I don't recall whether it was an error, or whether they inherited the configury from GCC that disabled shared libraries (for some other reason). The responses I got on the MinGW list (around 1/6/2002) indicated that I should just use the GNUstep version. The only indication I see of *why* is that the GNUstep version had different configury bits and a .def file to export the right symbols. I'm assuming there was some real problem, but it's been so long ago that I may be misremembering and it might be that MinGW's problem is an effect of GCC's problem, not the other way around. [...] > building libobjc as static on MinGW is not really a solution either, > as it > seems a libobjc.a on MinGW is not really a usable thing :-) [I think > the > problem starts when people build all other libraries as DLLs, and > mixing > DLLs and static libs doesn't seem a good thing ... well I don't really > know, but that's what I heard]. Building libobjc static under MinGW doesn't work well if your other libraries are DLLs _and_ if you want to get good warnings about undefined symbols in your DLLs. You can link the static library into main application and then not link it into your DLLs (linking in both causes madness since you get multiple copies of the ObjC runtime data). I don't recall why didn't go this direction unless it was that I somehow couldn't get DLLs to link with the undefined ObjC symbols... > I suppose what we'd really want then is to fix building the libobjc > shipped with GCC as a DLL on MinGW. :-) > > I don't have the time to work on this. Yes, I'd definitely like this -- assuming ObjC as a shared library works in GCC now, I can maybe scrounge up some time to get it working on MinGW. I assume all I'd need to do would be to remove 'AC_DISABLE_SHARED' and then reconfigure? -tim ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [3.2/3.3/HEAD] shared libobjc not built 2003-01-03 0:46 ` Timothy J. Wood @ 2003-01-03 3:55 ` Nicola Pero 2003-01-04 3:28 ` Timothy J. Wood 0 siblings, 1 reply; 13+ messages in thread From: Nicola Pero @ 2003-01-03 3:55 UTC (permalink / raw) To: Timothy J. Wood; +Cc: Andrea 'fwyzard' Bocci, Matthias Klose, gcc > > I suppose what we'd really want then is to fix building the libobjc > > shipped with GCC as a DLL on MinGW. :-) > > > > I don't have the time to work on this. > > Yes, I'd definitely like this -- assuming ObjC as a shared library > works in GCC now, I can maybe scrounge up some time to get it working > on MinGW. libobjc as a shared library does work in GCC, I think it works at least on GNU/linux, *bsd and Sun solaris. If you can get some time to get it working on MinGW, that would be great :-) At an innocent thought, it looks like it shouldn't be very difficult, since I suppose there should be plenty of packages built using autoconf and libtool which compile libraries as DLL on MinGW, and if you get in trouble, you can just peek what other packages are doing :-) But maybe I'm missing something basic, as I have no real experience on Win32. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [3.2/3.3/HEAD] shared libobjc not built 2003-01-03 3:55 ` Nicola Pero @ 2003-01-04 3:28 ` Timothy J. Wood 2003-01-04 5:58 ` Timothy J. Wood 2003-01-04 18:10 ` Alexandre Oliva 0 siblings, 2 replies; 13+ messages in thread From: Timothy J. Wood @ 2003-01-04 3:28 UTC (permalink / raw) To: Nicola Pero Cc: gcc, Matthias Klose, Andrea 'fwyzard' Bocci, mingw-patches On Thursday, January 2, 2003, at 07:54 PM, Nicola Pero wrote: > If you can get some time to get it working on MinGW, that would be > great > :-) OK, I have it generating a dll file now. I still need to test if ObjC *works* with the DLL, but I thought I'd run this diff out to see if anyone spots any problems this might cause (I can't imagine what, but...) This patch is against the gcc-3.2.1-20021201-3 MinGW tarball, but I wouldn't be surprised if it worked on the head too :) --- ./ltcf-c.sh Fri Aug 31 17:47:19 2001 +++ ../../gcc-3.2.1-20021201-3/ltcf-c.sh Fri Jan 3 19:18:51 2003 @@ -102,7 +102,7 @@ # hardcode_libdir_flag_spec is actually meaningless, as there is # no search path for DLLs. hardcode_libdir_flag_spec='-L$libdir' - allow_undefined_flag=unsupported + allow_undefined_flag= always_export_symbols=yes extract_expsyms_cmds='test -f $output_objdir/impgen.c || \ @@ -160,9 +160,9 @@ _lt_hint=1; cat $export_symbols | while read symbol; do set dummy \$symbol; - case \[$]# in - 2) echo " \[$]2 @ \$_lt_hint ; " >> $output_objdir/$soname-def;; - *) echo " \[$]2 @ \$_lt_hint \[$]3 ; " >> $output_objdir/$soname-def;; + case \$# in + 2) echo " \$2 @ \$_lt_hint ; " >> $output_objdir/$soname-def;; + *) echo " \$2 @ \$_lt_hint \$3 ; " >> $output_objdir/$soname-def;; esac; _lt_hint=`expr 1 + \$_lt_hint`; done; This turns off the setting of 'allow_undefined_flag=unsupported' since the ObjC DLL doesn't *have* any undefined symbols, so there is no need to allow them! Also, this changes the shell syntax to not bork the defs file -- It could well be that /bin/sh is busted on Mac OS X (from whence I'm cross compiling), but it is now bash: % /bin/sh --version GNU bash, version 2.05a.0(1)-release (powerpc-apple-darwin6.0) Copyright 2001 Free Software Foundation, Inc. ... so I'd expect it to be reasonably close to what other folks have. I'll let you all know if I can get the DLL actually working in a bit. :) -tim ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [3.2/3.3/HEAD] shared libobjc not built 2003-01-04 3:28 ` Timothy J. Wood @ 2003-01-04 5:58 ` Timothy J. Wood 2003-01-04 14:23 ` [MinGW-patches] " Earnie Boyd 2003-01-04 18:10 ` Alexandre Oliva 1 sibling, 1 reply; 13+ messages in thread From: Timothy J. Wood @ 2003-01-04 5:58 UTC (permalink / raw) To: Nicola Pero Cc: gcc, Matthias Klose, Andrea 'fwyzard' Bocci, mingw-patches On Friday, January 3, 2003, at 07:28 PM, Timothy J. Wood wrote: > OK, I have it generating a dll file now. I still need to test if > ObjC *works* with the DLL, but I thought I'd run this diff out to see > if anyone spots any problems this might cause (I can't imagine what, > but...) The DLL seems to work. The only issues are: - The install doesn't create a symlink from from libobjc.dll to libobjc-1.dll (my cross host is Unix, so a symlink should work fine) - '--disable-static' doesn't prevent the libobjc.a from getting built Still, the patch seems like a big improvement since I can actually *use* a DLL now. I can manually fix the items above trivially, so if someone could commit the ltcf-c.sh patch in MinGW and on the head of whatever GCC branches are appropriate, that would be great (or I can send the patch again to gcc-patches, if that is required). -tim ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [MinGW-patches] Re: [3.2/3.3/HEAD] shared libobjc not built 2003-01-04 5:58 ` Timothy J. Wood @ 2003-01-04 14:23 ` Earnie Boyd 0 siblings, 0 replies; 13+ messages in thread From: Earnie Boyd @ 2003-01-04 14:23 UTC (permalink / raw) To: Timothy J. Wood Cc: Nicola Pero, gcc, Matthias Klose, Andrea 'fwyzard' Bocci, mingw-patches Your patch were for sections of libtool. Only the cvs HEAD version of libtool will work properly for the mingw32 target. Come to think of it, I don't know that it's been tested in a cross build. I know that work is underway to update the GCC configury to the most current of autotools. If this weren't GCC I'd suggest updating the configury. As it is, you may wish to take a look at the libtool cvs HEAD to see what else you may need to change for this particular problem. Earnie. Timothy J. Wood wrote: > > On Friday, January 3, 2003, at 07:28 PM, Timothy J. Wood wrote: > >> OK, I have it generating a dll file now. I still need to test if >> ObjC *works* with the DLL, but I thought I'd run this diff out to see >> if anyone spots any problems this might cause (I can't imagine what, >> but...) > > > The DLL seems to work. > > The only issues are: > > - The install doesn't create a symlink from from libobjc.dll to > libobjc-1.dll (my cross host is Unix, so a symlink should work fine) > - '--disable-static' doesn't prevent the libobjc.a from getting built > > Still, the patch seems like a big improvement since I can actually > *use* a DLL now. I can manually fix the items above trivially, so if > someone could commit the ltcf-c.sh patch in MinGW and on the head of > whatever GCC branches are appropriate, that would be great (or I can > send the patch again to gcc-patches, if that is required). > > -tim > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > MinGW-patches mailing list > MinGW-patches@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-patches > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [3.2/3.3/HEAD] shared libobjc not built 2003-01-04 3:28 ` Timothy J. Wood 2003-01-04 5:58 ` Timothy J. Wood @ 2003-01-04 18:10 ` Alexandre Oliva 1 sibling, 0 replies; 13+ messages in thread From: Alexandre Oliva @ 2003-01-04 18:10 UTC (permalink / raw) To: Timothy J. Wood Cc: Nicola Pero, gcc, Matthias Klose, Andrea 'fwyzard' Bocci, mingw-patches On Jan 4, 2003, "Timothy J. Wood" <tjw@omnigroup.com> wrote: > This turns off the setting of 'allow_undefined_flag=unsupported' > since the ObjC DLL doesn't *have* any undefined symbols, Then it can be linked with libtool's -no-undefined flag, and then libtool will create a dynamic library. Changing allow_undefined_flag will just cause libtool to attempt to build libraries that do have undefined symbols as shared, which fails. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2003-01-04 18:00 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-01-01 15:52 [3.2/3.3/HEAD] shared libobjc not built Matthias Klose 2003-01-02 15:31 ` Andrea 'fwyzard' Bocci 2003-01-02 15:48 ` Nicola Pero [not found] ` <Pine.LNX.4.21.0301021543470.3304-100000@nicola.brainstorm. co.uk> 2003-01-02 16:06 ` Andrea 'fwyzard' Bocci 2003-01-02 16:32 ` Nicola Pero 2003-01-02 20:54 ` Timothy J. Wood 2003-01-03 0:01 ` Nicola Pero 2003-01-03 0:46 ` Timothy J. Wood 2003-01-03 3:55 ` Nicola Pero 2003-01-04 3:28 ` Timothy J. Wood 2003-01-04 5:58 ` Timothy J. Wood 2003-01-04 14:23 ` [MinGW-patches] " Earnie Boyd 2003-01-04 18:10 ` Alexandre Oliva
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).