Re: Tk lib build doesn't look in the Tcl build directory

Re: Tk lib build doesn't look in the Tcl build directory

[Mo DeJong]

>> Am I the only one seeing this?  It would seem that the Tk build requires
>> all the Tcl stuff to have been /installed/, not just built, before it itself
>> can build.  Perhaps the majority (totality?) of the developers already have
>> a Tcl installation somewhere in the default paths searched by the linker?

>What does "cat config.status" give? I just built for linux with and
>without --enable-shared, and it worked just fine.

>Is it pulling in the right tclConfig.sh (the one  in the build tree). Tcl
>should definately not need to be installed to build tk in our tree.

The problem here only shows up when --enable-shared is passed
and that was never tested as part of the 8.3 upgrade because we
always build static under Unix. At any rate, here is the most
simple little fix for the problem.

2002-07-14  Mo DeJong  <supermo@bayarea.net>

	* unix/configure: Regen.
	* unix/configure.in: Use TCL_BUILD_STUB_LIB_SPEC instead of
	TCL_STUB_LIB_SPEC when defining MAKE_LIB since we want to
	link to the libtclstub in the build directory.

Index: unix/configure.in
===================================================================
RCS file: /cvs/src/src/tk/unix/configure.in,v
retrieving revision 1.6
diff -u -r1.6 configure.in
--- unix/configure.in   9 Feb 2002 18:54:17 -0000       1.6
+++ unix/configure.in   15 Jul 2002 06:44:58 -0000
@@ -434,7 +434,7 @@
 if test "${SHARED_BUILD}" = "1" -a "${SHLIB_SUFFIX}" != ""; then
     TK_SHLIB_CFLAGS="${SHLIB_CFLAGS}"
     TCL_TOOL_SHARED_LIB_LONGNAME(TK_LIB_FILE, tk, ${TK_SHARED_LIB_SUFFIX})
-    MAKE_LIB="\${SHLIB_LD} -o \${TK_LIB_FILE} \${OBJS} \$(TK_LD_SEARCH_FLAGS) ${TCL_STUB_LIB_SPEC} \${LIBS}"
+    MAKE_LIB="\${SHLIB_LD} -o \${TK_LIB_FILE} \${OBJS} \$(TK_LD_SEARCH_FLAGS) ${TCL_BUILD_STUB_LIB_SPEC} \${LIBS}"
     RANLIB=":"
 
 #    TCL_STUB_FLAGS="-DUSE_TCL_STUBS"

Re: Tk lib build doesn't look in the Tcl build directory

[Phil Edwards]

On Mon, Jul 15, 2002 at 09:45:00AM -0700, Keith Seitz wrote:
> On Mon, 15 Jul 2002, Phil Edwards wrote:
> 
> > (I didn't know that the shared library is a relatively recent thing.
> > It explains some of the other hacks I have in my local tree, e.g., don't
> > run ranlib on a .so.)
> 
> I fixed enable-shared a long time ago, but I must have missed this
> instance (because it worked for me).

Somewhere, a few moons ago, I found a link problem that only manifested
on my non-RH systems, because a particular library happened to be in
/usr/lib under the default RH install.  On the other boxes, something in
the insight/gdb build was failing to link due to the missing library --
which was present in the tree, just not in a directory that was searched.
I sent a message to some list somewhere, but I don't recall which.
I should hunt it down just for completeness.

> Anyway, as soon as I've convinced myself that everything is okay, I'll
> commit Mo's patch.

Thanks very much for the help!


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Tk lib build doesn't look in the Tcl build directory

[Keith Seitz]

On Mon, 15 Jul 2002, Phil Edwards wrote:

> (I didn't know that the shared library is a relatively recent thing.
> It explains some of the other hacks I have in my local tree, e.g., don't
> run ranlib on a .so.)

I fixed enable-shared a long time ago, but I must have missed this
instance (because it worked for me).

Anyway, as soon as I've convinced myself that everything is okay, I'll
commit Mo's patch.

Keith

Re: Tk lib build doesn't look in the Tcl build directory

[Phil Edwards]

On Mon, Jul 15, 2002 at 09:16:49AM -0700, Keith Seitz wrote:
> On Mon, 15 Jul 2002, Phil Edwards wrote:
> 
> > So now instead of MAKE_LIB reading "-L{prefix}/lib -lstubname" it reads
> > "{build}/stubname.a" explicitly.  And this works.
> 
> Hmmm. Odd. Mine builds just fine without any of this. Alas, as Mo and you
> indicate, it seems that this is necessary. At the very least, it seems
> that it is correct to use the build spec in our tree.

Ah, cool.  I just now went to the archives and read Mo's message.

(I didn't know that the shared library is a relatively recent thing.
It explains some of the other hacks I have in my local tree, e.g., don't
run ranlib on a .so.)

Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Tk lib build doesn't look in the Tcl build directory

[Keith Seitz]

On Mon, 15 Jul 2002, Phil Edwards wrote:

> So now instead of MAKE_LIB reading "-L{prefix}/lib -lstubname" it reads
> "{build}/stubname.a" explicitly.  And this works.

Hmmm. Odd. Mine builds just fine without any of this. Alas, as Mo and you
indicate, it seems that this is necessary. At the very least, it seems
that it is correct to use the build spec in our tree.

I'll check it in.
Keith

Re: Tk lib build doesn't look in the Tcl build directory

[Phil Edwards]

On Mon, Jul 15, 2002 at 08:42:32AM -0700, Keith Seitz wrote:
> On Mon, 15 Jul 2002, Phil Edwards wrote:
> 
> > Which config.status?  The one in {build}/tcl/unix or the one in
> > {build}/tk/unix?  Or a third one?  I looked through the first two and
> > nothing jumped out at me.
> 
> Any of them will do. It'll just tell me how you configured your toolchain
> (host, target, build).

Oh, that.  It's an i686 native build.  Here's the toplevel config.status
(the nice tiny one):

  #!/bin/sh
  # This file was generated automatically by configure.  Do not edit.
  # This directory was configured as follows:
  /home/pme/src/unified/configure
  --with-gcc-version-trigger=/home/pme/src/unified/gcc/version.c
  --host=i686-pc-linux-gnu --prefix=/home/pme/build/install-2002-07-15
  --quiet --enable-shared --enable-languages=c++ --disable-nls --disable-sim
  --enable-version-specific-runtime-libs --enable-install-libiberty
  --enable-concept-checks --enable-symvers --enable-gdbtk --with-dwarf2
  --norecursion
  #  using "mt-frag"


> > > Is it pulling in the right tclConfig.sh (the one  in the build tree).
> >
> > How do I tell?
> 
> Take a look at the config.cache in your build directory. Look for a
> variable with "tclconfig" in it. It should be pointing to a file in the
> source tree. If not, it got the wrong one.

It's getting the right one:

11% cd build/build-2002-07-15
12% grep tclconfig config.cache
ac_cv_c_itclconfig=${ac_cv_c_itclconfig=/home/pme/build/build-2002-07-15/itcl/itcl}
ac_cv_c_tclconfig=${ac_cv_c_tclconfig=/home/pme/build/build-2002-07-15/tcl/unix}
13% ls -lF tcl/unix/tclConfig.sh
-rw-r--r--    1 pme      pme          7449 Jul 15 10:40 tcl/unix/tclConfig.sh
14% grep TCL_STUB_LIB_SPEC tcl/unix/tclConfig.sh
TCL_STUB_LIB_SPEC='-L/home/pme/build/install-2002-07-15/lib -ltclstub8.3${TCL_DBGX}'
15%


I opened tclConfig.sh, intending to hack the build path in there just so
I can get the rest of the tree to build, and noticed the other variables
alongside TCL_STUB_LIB_SPEC.  So instead of changing that file, I went
back into the source and made this change instead:


26% cvs diff -u3 configure.in
Index: configure.in
===================================================================
RCS file: /home/pme/Repositories/srctree/src/tk/unix/configure.in,v
retrieving revision 1.6
diff -u -3 -r1.6 configure.in
--- configure.in        9 Feb 2002 18:54:17 -0000       1.6
+++ configure.in        15 Jul 2002 16:05:28 -0000
@@ -434,7 +434,7 @@
 if test "${SHARED_BUILD}" = "1" -a "${SHLIB_SUFFIX}" != ""; then
     TK_SHLIB_CFLAGS="${SHLIB_CFLAGS}"
     TCL_TOOL_SHARED_LIB_LONGNAME(TK_LIB_FILE, tk, ${TK_SHARED_LIB_SUFFIX})
-    MAKE_LIB="\${SHLIB_LD} -o \${TK_LIB_FILE} \${OBJS} \$(TK_LD_SEARCH_FLAGS) ${TCL_STUB_LIB_SPEC} \${LIBS}"
+    MAKE_LIB="\${SHLIB_LD} -o \${TK_LIB_FILE} \${OBJS} \$(TK_LD_SEARCH_FLAGS) ${TCL_BUILD_STUB_LIB_PATH} \${LIBS}"
     RANLIB=":"

 #    TCL_STUB_FLAGS="-DUSE_TCL_STUBS"


So now instead of MAKE_LIB reading "-L{prefix}/lib -lstubname" it reads
"{build}/stubname.a" explicitly.  And this works.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Tk lib build doesn't look in the Tcl build directory

[Keith Seitz]

On Mon, 15 Jul 2002, Phil Edwards wrote:

> Which config.status?  The one in {build}/tcl/unix or the one in
> {build}/tk/unix?  Or a third one?  I looked through the first two and
> nothing jumped out at me.

Any of them will do. It'll just tell me how you configured your toolchain
(host, target, build).

> > Is it pulling in the right tclConfig.sh (the one  in the build tree).
>
> How do I tell?

Take a look at the config.cache in your build directory. Look for a
variable with "tclconfig" in it. It should be pointing to a file in the
source tree. If not, it got the wrong one.

Keith

Re: Tk lib build doesn't look in the Tcl build directory

[Phil Edwards]

On Sun, Jul 14, 2002 at 01:34:12PM -0700, Keith Seitz wrote:
> On Sun, 14 Jul 2002, Phil Edwards wrote:
> 
> > Am I the only one seeing this?  It would seem that the Tk build requires
> > all the Tcl stuff to have been /installed/, not just built, before it itself
> > can build.  Perhaps the majority (totality?) of the developers already have
> > a Tcl installation somewhere in the default paths searched by the linker?
> 
> What does "cat config.status" give? I just built for linux with and
> without --enable-shared, and it worked just fine.

Which config.status?  The one in {build}/tcl/unix or the one in
{build}/tk/unix?  Or a third one?  I looked through the first two and
nothing jumped out at me.

> Is it pulling in the right tclConfig.sh (the one  in the build tree).

How do I tell?


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Tk lib build doesn't look in the Tcl build directory

[Keith Seitz]

On Sun, 14 Jul 2002, Phil Edwards wrote:

> Am I the only one seeing this?  It would seem that the Tk build requires
> all the Tcl stuff to have been /installed/, not just built, before it itself
> can build.  Perhaps the majority (totality?) of the developers already have
> a Tcl installation somewhere in the default paths searched by the linker?

What does "cat config.status" give? I just built for linux with and
without --enable-shared, and it worked just fine.

Is it pulling in the right tclConfig.sh (the one  in the build tree). Tcl
should definately not need to be installed to build tk in our tree.

Keith

Tk lib build doesn't look in the Tcl build directory

[Phil Edwards]

Trying to build CVS GDB.  It fails in the tk stage with (command wrapped):

rm -f libtk8.3.so
gcc -pipe -shared -o libtk8.3.so [a gazillion object files] 
   -Wl,-rpath,/home/pme/build/install-2002-07-14/lib:/usr/X11R6/lib
   -L/home/pme/build/install-2002-07-14/lib -ltclstub8.3 -L/usr/X11R6/lib
   -lX11 -ldl -lieee -lm -lc
/usr/bin/ld: cannot find -ltclstub8.3
collect2: ld returned 1 exit status
gmake[2]: *** [libtk8.3.so] Error 1
gmake[2]: Leaving directory `/home/pme/build/build-2002-07-14/tk/unix'

Looking in the generated Makefile, I see the rule being fired is

${TK_LIB_FILE}: ${OBJS}
        rm -f ${TK_LIB_FILE}
        ${SHLIB_LD} -o ${TK_LIB_FILE} ${OBJS} $(TK_LD_SEARCH_FLAGS) -L/home/pme/build/install-2002-07-14/lib -ltclstub8.3${TCL_DBGX} ${LIBS}
        @case ${TK_LIB_FILE} in *.a) $(TK_RANLIB) ${TK_LIB_FILE};; esac

Okay, that's obvious enough.  The -l is being given, but not the correct
-L, since tcl hasn't been installed yet (the tree is still building).
Where is this line generated from?  The tk/unix/Makefile.in has the entire
line written as @MAKE_LIB@.

This in turn is set in tk/unix/configure.in with

    MAKE_LIB="\${SHLIB_LD} -o \${TK_LIB_FILE} \${OBJS} \$(TK_LD_SEARCH_FLAGS) ${TCL_STUB_LIB_SPEC} \${LIBS}"

so the "-L$prefix/lib -ltclstub8.3" is clearly the expansion of
TCL_STUB_LIB_SPEC.  However, this variable seems to be set in some other
tclConfig file, and that's as far as I got before giving up.


Am I the only one seeing this?  It would seem that the Tk build requires
all the Tcl stuff to have been /installed/, not just built, before it itself
can build.  Perhaps the majority (totality?) of the developers already have
a Tcl installation somewhere in the default paths searched by the linker?


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams