Tcl Source Code

On the SF compile farm. MacOS X 10.1, running the Tcl 
make fails because a ranlib call is not being done 
before ld.

It can be resolved by inserting the following lines 
at the end of the ${TCL_LIB_FILE} target:

        if test "x@DL_OBJS@" = "xtclLoadDyld.o"; then 
\
                $(RANLIB) ${TCL_LIB_FILE}; \
        fi

File Added - 28172: ranlib1.patch

Logged In: YES 
user_id=90580

your changes to Makefile.in did the trick, ranlib now gets run and 
everything links properly with --disable-shared. Thanks

Logged In: YES 
user_id=90858

I went ahead and checked out the 8.3 branch and reverted the
changes while adding the RANLIB=: bit back in. This should
fix things on systems where running ranlib is required.
It does not port back all the changes from the HEAD, I
just made the minimal change to get things working again.
As far as it not working on OS X, I just don't see why that
would happen now. Please try it out and let me know if
it is still a problem. Now of that DL_OBJS stuff should
have been in there, so I removed it.

Logged In: YES 
user_id=90580

the line with
test "x$DL_OBJS" = "xtclLoadAout.o"
has been in configure.in forever (at least since rev 1.57 in core-
8-3-1 from over 2 years ago), it seems to be a special case for 
"pseudo-static linking" (c.f. comments). It certainly has nothing to 
do with Darwin/MacOSX

however this test is what Jean-Claude apparently had adapted 
as a kind of platform check for Darwin in his original patch (based 
on the fact that DL_OBJS==tclLoadDyld.o only ever on Darwin)
His patch always did ranlib however and so broke dynamic 
linking on OSX. While I fixed that problem, I didn't change the 
test logic (because I didn't fully understand it until now...)

the right thing to do is to test against $system, it's also true that 
RANLIB=':' got lost somwhere in the shuffle as well. (it's there in 
rev 1.57)

would you then agree with something along the lines of the 
following patch to the current configure.in on the tip of core-8-3-
1-branch ?

I realize that there are probably better ways to do this but this 
rather crude method seems to result in the smallest possible 
patch for the bug at hand. It should not interfere with other 
systems since MAKE_LIB will only be changed when on Darwin 
with static linking on.

BTW, this builds fine on the compilefarm on FreeBSD 4.6-
STABLE both static and shared, not sure if that would have 
been one of the BSDs affected by the ranlib problems.

Index: configure.in
==================================================
=================
RCS file: /cvsroot/tcl/tcl/unix/configure.in,v
retrieving revision 1.57.2.11
diff -u -r1.57.2.11 configure.in
--- configure.in        24 Jul 2002 13:54:47 -0000      1.57.2.11
+++ configure.in        30 Jul 2002 09:40:22 -0000
@@ -389,6 +389,7 @@
        MAKE_LIB="\${STLIB_LD} \[$]@ \${OBJS}"
     else
        MAKE_LIB="\${SHLIB_LD} ${TCL_SHLIB_LD_EXTRAS} -o 
\[$]@ \${OBJS} ${SHLIB_LD_LIBS}"
+       RANLIB=":"
     fi
 else
     case $system in
@@ -405,9 +406,11 @@
     TCL_SHLIB_CFLAGS=""
     eval "TCL_LIB_FILE=libtcl${TCL_UNSHARED_LIB_SUFFIX}"
     MAKE_LIB="\${STLIB_LD} \[$]@ \${OBJS}"
-    if test "x$DL_OBJS" = "xtclLoadDyld.o"; then
-       MAKE_LIB="${MAKE_LIB} ; \${RANLIB} \$@"
-    fi
+    case $system in
+       Darwin-*)
+           MAKE_LIB="${MAKE_LIB} ; \${RANLIB} \$@"
+           ;;
+    esac
 fi

Logged In: YES 
user_id=90858

Oops, I forgot to mention the "other changes" I reverted.
I took a quick peek at the configure.in on the 8.3 branch
via CVSWeb and found the same broken code that I
just removed from the HEAD:

if test "${SHARED_BUILD}" = "1" -a "${SHLIB_SUFFIX}" != "" ;
then
    TCL_SHLIB_CFLAGS="${SHLIB_CFLAGS}"
    eval "TCL_LIB_FILE=libtcl${TCL_SHARED_LIB_SUFFIX}"
    if test "x$DL_OBJS" = "xtclLoadAout.o"; then
        MAKE_LIB="\${STLIB_LD} \[$]@ \${OBJS}"
    else
        MAKE_LIB="\${SHLIB_LD} ${TCL_SHLIB_LD_EXTRAS} -o
\[$]@ \${OBJS} ${SHLIB_
LD_LIBS}"
    fi
else


I have no idea how this got into such a state, but it appears to
be linking a shared library with STLIB_LD (totally wrong)
and is once again running RANLIB based on the dynamic
loading implementation. This too should be reverted in the
8.3 branch since it will break other systems.

Logged In: YES 
user_id=90858

You mentioned that you checked the
ranlib_core-8-3-1-branch.patch file into the
8.3 branch. That will break the build under BSD
as well as others and so it should be reverted.

Tcl bug 587299 is an example of what goes wrong.
I assume you are not seeing the bug because the
Linux and Solaris versions of ar automatically
invoke ranlib behind the scenes to create an archive
index. Some systems do not do this.

Even if nobody reported this as a bug, you should
still revert the patch. Why? Because it is totally
the wrong thing to be doing. First off, the implementation
of dynamic loading has nothing to do with ranlib
and static libs, so why are you making it depend
on DL_OBJS? Second, the RANLIB variable should
be set to : when building a shared library.

Logged In: YES 
user_id=90580

No, you're confusing Jim's macosx-8-4-branch using Apple's GUI 
compiler tools and native GUI with my ongoing work to maintain 
classical 'configure; make' on Darwin/OSX.
There is nothing new about this support, it's been there since 
8.3.1 and tcl built thusly has in fact been shipping in the 
MacOSX retail product since it's very first release 2 years ago...

Maybe you can explain how the attached ranlib_core-8-3-1-
branch.patch to configure.in breaks the build on other systems?
It certainly doesn't affect the x86 linux and solaris builds I've 
tested. (both --enable-shared and --disable-shared)

Logged In: YES 
user_id=90858

I would rather not backport all the needed changes to get
the 8.3
branch working with OS X. The build system in 8.3 is so out of
date WRT the HEAD, it would likely take a whole lot of work.
If you have checked ranlib related changes into the 8.3 branch,
I would rather see them reverted since they will break the
build for a number of systems that already work. The 8.3
branch should be used for bug fixes only, adding support for
a new system at the cost of breaking others does not seem
to fit that bill.

Logged In: YES 
user_id=90580

Mo,

thanks for looking into this. The problem was that before your 
latest fixes, MAKE_LIB on OSX did not run ranlib on libtcl.a 
before linking tclsh which caused that link to fail (ranlib _was_ 
run at installation time however)

however, with your latest work this works fine for me now, i.e. 
building tbe HEAD with --disable-shared now works for me on 
Darwin/OSX

could you take a look at this issue on core-8-3-1-branch as well? 
I had checked in the same change to configure.in there also, as 
the static linking problem on OSX exists there too of course.

(btw, you can test building on OSX yourself on the SF 
compilefarm cf.sf.net)

What were the other changes "from the Mac OS X branch" that 
you have reverted? was that just referring to your changes re. 
TCL_SHLIB_LD_EXTRAS or was there anything else?


JC,

not sure why this doesn't work for you, what are the errors you 
see when building the HEAD?
as long as your tcl.m4 has Mo's new
MAKE_LIB='${STLIB_LD} [$]@ ${OBJS} ; ${RANLIB} [$]@'
(i.e functionally equivalent on OSX to what I had added to 
configure.in earlier), static linking should work.

Logged In: YES 
user_id=90858

While the approach in question may have worked for you, it
broke the
build for other systems. Besides, it just did not make any
sense. What
on earth does the implementation of dynamic loading have to
do with
whether ranlib is run on a generated .a archive?

Even if those two things were related, the decision of when to
run ranlib must be made in the configure script, not the
Makefile.

You mention that ranlib is not getting run on OS X. I assume you
mean at build and not install time, right? The right way to
address
this is to take a peek at the SC_CONFIG_CFLAGS macro and
see what MAKE_LIB is getting set to. I assume that the
AC_PROG_RANLIB is not finding ranlib and this is causing
MAKE_LIB to not include a ranlib call. Is that the case?

Logged In: YES 
user_id=1983

Except that now, on OS X, --disable-shared doesn't build at 
all.

I don't mind having my suggestion ignored or reverted, all I 
can say is that what I originally submitted worked for me, 
and that we're not getting very far this way :(

Mo, I'll rephrase the problem, in the hope that it works 
better for you this way: on OS X, a "--disable-shared" (i.e. 
static) build fails, because a ranlib call is being left out 
(in two places in the makefile, in fact).

Logged In: YES 
user_id=90858

This change along with a couple of others from the Mac OS X
branch
have been reverted as of 2002-07-27. They were just wrong and
they broke the build on other systems.

I have gone ahead and created a new set of build and install
commands and defined them in the SC_CONFIG_CFLAGS
macro in tcl.m4 (see MAKE_LIB, MAKE_STUB_LIB,
INSTALL_LIB, and INSTALL_STUB_LIB).

If you are still having problems with ranlib related issues
related to OS X, please take a look at the new approach
and assign any related patches to me. Just an FYI, I don't
see how the DL_OBJS in use could have anything to do
with ranlib, so please don't go down that route again.

Logged In: YES 
user_id=90580

commited to HEAD & core-8-3-1-branch

File Added - 27643: ranlib_core-8-3-1-branch.patch

Logged In: YES 
user_id=90580

attached patch to core-8-3-1-branch

File Deleted - 27640: 



File Added - 27642: ranlib_HEAD.patch

Logged In: YES 
user_id=90580

attached patch to HEAD

File Added - 27640: ranlib.patch

Logged In: YES 
user_id=90580

this fix is incorrect, it breaks the shared build as ranlib fails on 
dynamic libraries:
ranlib: file: libtcl8.4.dylib is not an archive

to correctly fix static linking (i.e. configured with --disable-shared), 
IMHO it's best to change the definition of MAKE_LIB in 
configure.in as in the attached patch (which also reverses the 
present incorrect change)

I'll check this in if Vince agrees