[3.2/3.3/HEAD] shared libobjc not built

[3.2/3.3/HEAD] shared libobjc not built

[Matthias Klose]

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
[...]

Re: [3.2/3.3/HEAD] shared libobjc not built

[Andrea 'fwyzard' Bocci]

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 

Re: [3.2/3.3/HEAD] shared libobjc not built

[Nicola Pero]

> >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!

Re: [3.2/3.3/HEAD] shared libobjc not built

[Andrea 'fwyzard' Bocci]

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

Re: [3.2/3.3/HEAD] shared libobjc not built

[Nicola Pero]

> > > 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.

Re: [3.2/3.3/HEAD] shared libobjc not built

[Timothy J. Wood]

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

Re: [3.2/3.3/HEAD] shared libobjc not built

[Nicola Pero]

> > 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.

Re: [3.2/3.3/HEAD] shared libobjc not built

[Timothy J. Wood]

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

Re: [3.2/3.3/HEAD] shared libobjc not built

[Nicola Pero]

> > 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.

Re: [3.2/3.3/HEAD] shared libobjc not built

[Timothy J. Wood]

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

Re: [3.2/3.3/HEAD] shared libobjc not built

[Timothy J. Wood]

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

Re: [MinGW-patches] Re: [3.2/3.3/HEAD] shared libobjc not built

[Earnie Boyd]

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
> 

Re: [3.2/3.3/HEAD] shared libobjc not built

[Alexandre Oliva]

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