MacOS compilation

Hi all,

Following an old thread on this mailing-list:
    https://lists.isc.org/pipermail/inn-workers/2010-January/017082.html

Recent discussions on de.comm.software.newsserver led Dennis Preiser to
investigate.  He found out that:

Root cause seems to be that ranlib behaves different on MacOSX. By
default, ranlib (actual libtool, ranlib is a symbolic link to libtool)
doesn't put common symbols in the index. From ranlib(1):

       -c     Include  common symbols as definitions with respect to the
              table of contents.  This is seldom the  intended  behavior
              for  linking from a library, as it forces the linking of a
              library member  just  because  it  uses  an  uninitialized
              global  that  is  undefined  at that point in the linking.
              This option is included only because this was the original
              behavior of ranlib.  This option is not the default.

Another short explanation of this issue can be found here:
    http://lists.gnu.org/archive/html/libtool/2002-07/msg00025.html

With the following changes, I can run './configure && make' without
errors on MacOSX:

diff -urp inn-2.5.2_orig/Makefile.global.in inn-2.5.2/Makefile.global.in
--- inn-2.5.2_orig/Makefile.global.in	2010-03-24 21:10:36.000000000 +0100
+++ inn-2.5.2/Makefile.global.in	2011-05-16 19:10:35.000000000 +0200
 <at>  <at>  -193,7 +193,7 <at>  <at> 

Re: MacOS compilation

Julien ÉLIE <julien <at> trigofacile.com> writes:

> That's a very interesting idea.
> We should then check at configure time the platform on which we are
> compiling and add "-c" to RANLIB, if needed.

> I do not see any autoconf parameter that does it automatically.
> Does anyone know such a parameter?

I suspect this is one of those things that libtool just handles for us,
were we to use libtool for everything instead of making it optional.
We're somewhat unusual these days for using Autoconf and building
libraries but not using Libtool.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
_______________________________________________
inn-workers mailing list
inn-workers <at> lists.isc.org
https://lists.isc.org/mailman/listinfo/inn-workers

Re: MacOS compilation

Quoth Julien ÉLIE:
> We should then check at configure time the platform on which we are
> compiling and add "-c" to RANLIB, if needed.

If the problem is with common variables, wouldn't it be easier
to just make them non-common by adding initialisations?

/Bo Lindbergh

Quoth Julien ÉLIE:
> We should then check at configure time the platform on which we are
> compiling and add "-c" to RANLIB, if needed.

If the problem is with common variables, wouldn't it be easier
to just make them non-common by adding initialisations?

/Bo Lindbergh

Re: MacOS compilation

Hi Bo,

> If the problem is with common variables, wouldn't it be easier to
> just make them non-common by adding initialisations?

Your suggestion fixes the issue.  Just compiled fine on Darwin.

We can even remove buffindexed/shmem.o from the buffindexed dependencies.

Index: storage/buffindexed/ovmethod.mk
===================================================================
--- storage/buffindexed/ovmethod.mk	(révision 9189)
+++ storage/buffindexed/ovmethod.mk	(copie de travail)
 <at>  <at>  -5,5 +5,4  <at>  <at> 

 buffindexed/buffindexed_d: buffindexed/buffindexed_d.o libstorage.$(EXTLIB) $(LIBHIST)
 	$(LIBLD) $(LDFLAGS) -o $ <at>  buffindexed/buffindexed_d.o \
-	    buffindexed/shmem.o expire.o ov.o \
 	    $(LIBSTORAGE) $(LIBHIST) $(LIBINN) $(STORAGE_LIBS) $(LIBS)
Index: storage/ov.c
===================================================================
--- storage/ov.c	(révision 9189)
+++ storage/ov.c	(copie de travail)
 <at>  <at>  -28,8 +28,8  <at>  <at> 
 static bool             OVdelayrm;
 static OV_METHOD	ov;

-time_t	OVrealnow;
-bool    OVstatall;
+time_t	OVrealnow = 0;

Re: MacOS compilation

Hi Russ,

> I suspect this is one of those things that libtool just handles for us,
> were we to use libtool for everything instead of making it optional.
> We're somewhat unusual these days for using Autoconf and building
> libraries but not using Libtool.

Wouldn't using "--enable-libtool" do the trick right now?
or should we really have a look at switching to Automake and Libtool?

--

-- 
Julien ÉLIE

« Aux quatre coins de l'Hexagone. »
_______________________________________________
inn-workers mailing list
inn-workers <at> lists.isc.org
https://lists.isc.org/mailman/listinfo/inn-workers

Re: MacOS compilation

Julien ÉLIE <julien <at> trigofacile.com> writes:
> Hi Russ,

>> I suspect this is one of those things that libtool just handles for us,
>> were we to use libtool for everything instead of making it optional.
>> We're somewhat unusual these days for using Autoconf and building
>> libraries but not using Libtool.

> Wouldn't using "--enable-libtool" do the trick right now?

It would, yes.

> or should we really have a look at switching to Automake and Libtool?

I think it would reduce complexity in the long run, but I know some people
don't like Automake very much.  My preferred way to use Automake is also
non-recursive, which makes it hard to build a specific directory the way
that one can easily do in our current code layout.  People may not like
that.

I'm also not quite sure how to manage the current site infrastructure in
Automake, although there's probably some way to do it.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
_______________________________________________
inn-workers mailing list