[1681] in Kerberos_V5_Development
Re: something useful
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Fri Aug 30 19:09:16 1996
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: Ken Raeburn <raeburn@cygnus.com>, Kev <klmitch@MIT.EDU>, krbdev@MIT.EDU
In-Reply-To: Your message of "Fri, 30 Aug 1996 18:46:37 EDT."
<9608302246.AA26679@dcl.MIT.EDU>
Date: Fri, 30 Aug 1996 19:08:44 EDT
From: Marc Horowitz <marc@MIT.EDU>
In message <9608302246.AA26679@dcl.MIT.EDU>, "Theodore Y. Ts'o" <tytso@MIT.EDU> writes:
>> 2) From the makefile.in, put in a constrct of the form:
>>
>> make -f $(top_srcdir)/lib/@SHLIB_MAGIC@ <arg1> <arg2>
I don't think you need to go as far as calling another Makefile. You
could have a platform-dependent switch in aclocal.m4, called from
configure.in, which set a few variables
CC_SHOBJ
LD_SHLIB
SHOBJ_EXT
SHLIB_EXT
then, you could have, probably in pre.in or something similar:
CC_SHOBJ = @CC_SHOBJ@
LD_SHLIB = @LD_SHLIB@
SHOBJ_EXT = @SHOBJ_EXT@
SHLIB_EXT = @SHLIB_EXT@
.c.so:
$(CC_SHOBJ) -o $@ $<
and in the Makefile.in:
SHLIB_OBJS = foo.$(SHOBJ_EXT) bar.$(SHOBJ_EXT) baz.$(SHOBJ_EXT)
libfoo.$(SHLIB_EXT): $(SHLIB_OBJS) $(SHLIB_DEPS)
$(LD_SHLIB) -o libfoo.$(SHLIB_EXT) $(SHLIB_OBJS) $(SHLIB_DEPS)
This is only a general idea; it's probably not exactly right as
stated.
If necessary, CC_SHOBJ and LD_SHLIB on some platforms could refer to
shell scripts or batch files, but I suspect this will be unnecessary
on most platforms.
The reason for .c.so, but $(SHOBJ_EXT) in the object list, is that on
some platforms, -fpic or something like it is needed. Then, you would
set SHOBJ_EXT to "so", and the extra files would be built with
whatever options were included in CC_SHOBJ. On other platforms, there
is no difference between the objects for static and shared libraries.
On those platforms, set SHOBJ_EXT to "o", and the .c.so rule will
never be used, and the right thing will happen. (For readability, we
might use $(SO) instead of $(SHOBJ_EXT).)
I'm not sure exactly how to deal with shlib version numbers, but Ted's
suggestions don't deal with that, either. The right thing here is
probably to have some inline makefile (pre.in?) declare the versions
of the shared libraries explicitly in one place. This should be
fixed for a given release, anyway.
Marc
