Tcl

Hi Philipp,


Philipp Roessler <Der_WACHTMEISTER@...> writes:

> I have a C++ program embedding Tcl/Tk. The compiled object files have
> been linked to the tcl and tk libraries I built from source:
>   "g++ -L/Library/Frameworks/Tk.framework -o Invert ../tclbuf.o
>   ../Image/Image.o ../Image/TkRGBImage.o ../Filter/Invert.o main.o
>   -lstdc++ -ltcl8.4 -lTk8.4"
>
> Now, since Mac OS X 10.3 I get dozens of linker warnings like
>   "ld: warning multiple definitions of symbol _TclFSSetPathDetails
>    /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl(tclIOUtil.o)
>    definition of _TclFSSetPathDetails
>    /usr/lib/libtcl8.4.dylib(tclIOUtil.o) definition of
>    _TclFSSetPathDetails".
>
> How do I make the linker use only those libraries that I want?

As your linker error indicates, you have two Tcl libraries installed,
one in /usr/lib/libtcl8.4.dylib and one as a framework in
/Library/Frameworks/Tcl.framework.  You are using the Tk.framework
which is linked to the Tcl.framework, so you want to link only to that
yourself, too.  Try

   OBJS = ../tclbuf.o ../Image/Image.o ../Image/TkRGBImage.o \
          ../Filter/Invert.o main.o

   g++ -o Invert $(OBJS) -framework Tk -framework Tcl


benny

Am 01.12.2003 um 14:28 schrieb Benjamin Riefenstahl:
>
> Philipp Roessler <Der_WACHTMEISTER@...> writes:
>
>> I have a C++ program embedding Tcl/Tk. The compiled object files have
>> been linked to the tcl and tk libraries I built from source:
>>   "g++ -L/Library/Frameworks/Tk.framework -o Invert ../tclbuf.o
>>   ../Image/Image.o ../Image/TkRGBImage.o ../Filter/Invert.o main.o
>>   -lstdc++ -ltcl8.4 -lTk8.4"
>>
>> Now, since Mac OS X 10.3 I get dozens of linker warnings like
>>   "ld: warning multiple definitions of symbol _TclFSSetPathDetails
>>    /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl(tclIOUtil.o)
>>    definition of _TclFSSetPathDetails
>>    /usr/lib/libtcl8.4.dylib(tclIOUtil.o) definition of
>>    _TclFSSetPathDetails".
>>
>> How do I make the linker use only those libraries that I want?
>
> As your linker error indicates, you have two Tcl libraries installed,
> one in /usr/lib/libtcl8.4.dylib and one as a framework in
> /Library/Frameworks/Tcl.framework.  You are using the Tk.framework
> which is linked to the Tcl.framework, so you want to link only to that
> yourself, too.  Try
>
>    OBJS = ../tclbuf.o ../Image/Image.o ../Image/TkRGBImage.o \
>           ../Filter/Invert.o main.o
>
>    g++ -o Invert $(OBJS) -framework Tk -framework Tcl

I tried what you meant, but unfortunately the outcome is exactly the 
same =(

There must be a way to specify which libs to link and which not, no!?

Phil

On Dec 2, 2003, at 1:42 PM, Philipp Roessler wrote:

>
> Am 01.12.2003 um 14:28 schrieb Benjamin Riefenstahl:
>>
>> Philipp Roessler <Der_WACHTMEISTER@...> writes:
>>
>>> I have a C++ program embedding Tcl/Tk. The compiled object files have
>>> been linked to the tcl and tk libraries I built from source:
>>>   "g++ -L/Library/Frameworks/Tk.framework -o Invert ../tclbuf.o
>>>   ../Image/Image.o ../Image/TkRGBImage.o ../Filter/Invert.o main.o
>>>   -lstdc++ -ltcl8.4 -lTk8.4"
>>>
>>> Now, since Mac OS X 10.3 I get dozens of linker warnings like
>>>   "ld: warning multiple definitions of symbol _TclFSSetPathDetails
>>>    /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl(tclIOUtil.o)
>>>    definition of _TclFSSetPathDetails
>>>    /usr/lib/libtcl8.4.dylib(tclIOUtil.o) definition of
>>>    _TclFSSetPathDetails".
>>>
>>> How do I make the linker use only those libraries that I want?
>>
>> As your linker error indicates, you have two Tcl libraries installed,
>> one in /usr/lib/libtcl8.4.dylib and one as a framework in
>> /Library/Frameworks/Tcl.framework.  You are using the Tk.framework
>> which is linked to the Tcl.framework, so you want to link only to that
>> yourself, too.  Try
>>
>>    OBJS = ../tclbuf.o ../Image/Image.o ../Image/TkRGBImage.o \
>>           ../Filter/Invert.o main.o
>>
>>    g++ -o Invert $(OBJS) -framework Tk -framework Tcl
>
> I tried what you meant, but unfortunately the outcome is exactly the 
> same =(
>
> There must be a way to specify which libs to link and which not, no!?
>

Can you send us your exact newly failing command-line (plus error 
message).  If you don't say -ltcl8.4, the linker shouldn't be picking 
up the version of tcl in /usr/lib.

Jim

> Phil
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Tcl-mac mailing list
> Tcl-mac@...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>
--
Jim Ingham                                   jingham@...
Developer Tools
Apple Computer

Hi Philipp,


Philipp Roessler <Der_WACHTMEISTER@...> writes:
> I tried what you meant, but unfortunately the outcome is exactly the
> same =(

As Jim said, please post the exact command line that you used and the
exact error.

> There must be a way to specify which libs to link and which not,
> no!?

>> Philipp Roessler <Der_WACHTMEISTER@...> writes:
>>>   "g++ -L/Library/Frameworks/Tk.framework -o Invert ../tclbuf.o
>>>   ../Image/Image.o ../Image/TkRGBImage.o ../Filter/Invert.o main.o
>>>   -lstdc++ -ltcl8.4 -lTk8.4"

Your command line above *does* say "link to /usr/lib/libtcl8.4.dylib
*and* to the Tk framework".  That won't work, because the Tk framework
links to the Tcl framework, so in addition to the standalone Tcl lib,
the Tcl framework was also linked, leading to duplicate symbols.  At
least that is how I interprete the error message that you got.

> Am 01.12.2003 um 14:28 schrieb Benjamin Riefenstahl:
>>    OBJS = ../tclbuf.o ../Image/Image.o ../Image/TkRGBImage.o \
>>           ../Filter/Invert.o main.o
>>
>>    g++ -o Invert $(OBJS) -framework Tk -framework Tcl
>

This command line only mentions the frameworks, not any stand-alone
libraries.  You could try to leave out the "-framework Tcl", but that
shouldn't be necessary and it may lead to *undefined* symbols in turn.


benny

Am 02.12.2003 um 23:40 schrieb Jim Ingham:

>
> On Dec 2, 2003, at 1:42 PM, Philipp Roessler wrote:
>
>>
>> Am 01.12.2003 um 14:28 schrieb Benjamin Riefenstahl:
>>>
>>> Philipp Roessler <Der_WACHTMEISTER@...> writes:
>>>
>>>> I have a C++ program embedding Tcl/Tk. The compiled object files 
>>>> have
>>>> been linked to the tcl and tk libraries I built from source:
>>>>   "g++ -L/Library/Frameworks/Tk.framework -o Invert ../tclbuf.o
>>>>   ../Image/Image.o ../Image/TkRGBImage.o ../Filter/Invert.o main.o
>>>>   -lstdc++ -ltcl8.4 -lTk8.4"
>>>>
>>>> Now, since Mac OS X 10.3 I get dozens of linker warnings like
>>>>   "ld: warning multiple definitions of symbol _TclFSSetPathDetails
>>>>    /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl(tclIOUtil.o)
>>>>    definition of _TclFSSetPathDetails
>>>>    /usr/lib/libtcl8.4.dylib(tclIOUtil.o) definition of
>>>>    _TclFSSetPathDetails".
>>>>
>>>> How do I make the linker use only those libraries that I want?
>>>
>>> As your linker error indicates, you have two Tcl libraries installed,
>>> one in /usr/lib/libtcl8.4.dylib and one as a framework in
>>> /Library/Frameworks/Tcl.framework.  You are using the Tk.framework
>>> which is linked to the Tcl.framework, so you want to link only to 
>>> that
>>> yourself, too.  Try
>>>
>>>    OBJS = ../tclbuf.o ../Image/Image.o ../Image/TkRGBImage.o \
>>>           ../Filter/Invert.o main.o
>>>
>>>    g++ -o Invert $(OBJS) -framework Tk -framework Tcl
>>
>> I tried what you meant, but unfortunately the outcome is exactly the 
>> same =(
>>
>> There must be a way to specify which libs to link and which not, no!?
>>
>
> Can you send us your exact newly failing command-line (plus error 
> message).  If you don't say -ltcl8.4, the linker shouldn't be picking 
> up the version of tcl in /usr/lib.


Here is a small snippet of hundreds of lines of linking failures (which 
essentially all sound the same).

 > g++ -framework Tcl -framework Tk -o Invert ../tclbuf.o 
../Image/Image.o ../Image/TkRGBImage.o ../Filter/Invert.o main.o 
-lstdc++

ld: warning multiple definitions of symbol _TclFSSetPathDetails
/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl(tclIOUtil.o) 
definition of _TclFSSetPathDetails
/Library/Frameworks/Tcl.framework/Tcl(tclIOUtil.o) definition of 
_TclFSSetPathDetails
ld: warning multiple definitions of symbol _TclNewFSPathObj
/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl(tclIOUtil.o) 
definition of _TclNewFSPathObj
/Library/Frameworks/Tcl.framework/Tcl(tclIOUtil.o) definition of 
_TclNewFSPathObj
ld: warning multiple definitions of symbol _TclOpenFileChannelDeleteProc
/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl(tclIOUtil.o) 
definition of _TclOpenFileChannelDeleteProc
/Library/Frameworks/Tcl.framework/Tcl(tclIOUtil.o) definition of 
_TclOpenFileChannelDeleteProc
.
. (more ~490 lines like this)
.
ld: warning suggest use of -bind_at_load, as lazy binding may result in 
errors or different symbols being used
symbol _Tcl_GetServiceMode used from dynamic library 
/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl(tclNotify.o) not 
from earlier dynamic library 
/System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl(tclNotify.o)
symbol _Tcl_DeleteEventSource used from dynamic library 
/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl(tclNotify.o) not 
from earlier dynamic library 
/System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl(tclNotify.o)
symbol _Tcl_ServiceAll used from dynamic library 
/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl(tclNotify.o) not 
from earlier dynamic library 
/System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl(tclNotify.o)
.
. (more ~160 lines like this)
.

Really hope that this tells you something!

Phil

From your snippet, I note:


> /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl(tclIOUtil.o) 
> definition of _TclFSSetPathDetails
> /Library/Frameworks/Tcl.framework/Tcl(tclIOUtil.o) definition of 
> _TclFSSetPathDetails
>

The multiply defined symbols are not between the tcl framework & the 
tcl dylib anymore.  They are between two versions of the Tcl library 
WITHIN the Tcl framework...

/Library/Frameworks/Tcl.framework/Tcl should be a LINK to 
/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl.  From the error 
message you are getting it looks like the two are both actual files.  
Can you check this?  If they are both files you can fix the problem in 
the short term by deleting /Library/Frameworks/Tcl.framework/Tcl, and 
then replacing it with a link to the actual library.  Probably need to 
do the same for Tk.  But it would also be interesting to know how this 
happened.  It wasn't the case in the BI distro of 8.4.4 that I got from 
Daniel...

Jim
--
Jim Ingham                                   jingham@...
Developer Tools
Apple Computer

> From your snippet, I note:
>
>
>> /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl(tclIOUtil.o) 
>> definition of _TclFSSetPathDetails
>> /Library/Frameworks/Tcl.framework/Tcl(tclIOUtil.o) definition of 
>> _TclFSSetPathDetails
>>
>
> The multiply defined symbols are not between the tcl framework & the 
> tcl dylib anymore.  They are between two versions of the Tcl library 
> WITHIN the Tcl framework...
>
> /Library/Frameworks/Tcl.framework/Tcl should be a LINK to 
> /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl.

Actually, "/Library/Frameworks/Tcl.framework" is a symbolic link to  
"System/Library/Frameworks/Tcl.framework".
I never had a real Tcl.framework lying in /Library/Frameworks/, only 
soft links. Before Panther this pointed to a Tcl.framework residing in 
my home directory (in fact this is where the my Tk.framework lies).

Phil

How you get to Tcl.framework isn't really important, I think.  The 
important point is whether the Tcl file inside the Tcl.framework is an 
actual file or a link to the one in Versions/8.4.  The problem is that 
depending on how you happen to link to things, you can get the actual 
load command in the binary that links to Tcl to either be 
Tcl.framework/Tcl OR Tcl.framework/Versions/8.4/Tcl (or what seems to 
be the case for you, to BOTH).  Normally, it doesn't matter how you 
record the path to the file, since the linker resolves file system 
links and is smart enough to know that the two are actually the same 
file.  But if they aren't the same file, then the linker will bring in 
two copies of the Tcl library, and you will get link errors.

Jim

On Dec 3, 2003, at 11:05 AM, Philipp Roessler wrote:

>> From your snippet, I note:
>>
>>
>>> /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl(tclIOUtil.o) 
>>> definition of _TclFSSetPathDetails
>>> /Library/Frameworks/Tcl.framework/Tcl(tclIOUtil.o) definition of 
>>> _TclFSSetPathDetails
>>>
>>
>> The multiply defined symbols are not between the tcl framework & the 
>> tcl dylib anymore.  They are between two versions of the Tcl library 
>> WITHIN the Tcl framework...
>>
>> /Library/Frameworks/Tcl.framework/Tcl should be a LINK to 
>> /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl.
>
> Actually, "/Library/Frameworks/Tcl.framework" is a symbolic link to  
> "System/Library/Frameworks/Tcl.framework".
> I never had a real Tcl.framework lying in /Library/Frameworks/, only 
> soft links. Before Panther this pointed to a Tcl.framework residing in 
> my home directory (in fact this is where the my Tk.framework lies).
>
> Phil
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Tcl-mac mailing list
> Tcl-mac@...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>
--
Jim Ingham                                   jingham@...
Developer Tools
Apple Computer

Philipp,

On Thursday, Dec 4, 2003, at 06:05 Australia/Sydney, Philipp Roessler  
wrote:

> Actually, "/Library/Frameworks/Tcl.framework" is a symbolic link to   
> "System/Library/Frameworks/Tcl.framework".
> I never had a real Tcl.framework lying in /Library/Frameworks/, only  
> soft links. Before Panther this pointed to a Tcl.framework residing in  
> my home directory (in fact this is where the my Tk.framework lies).

so which Tcl.framework is Tk.framework linked to?

can you give us the results of

     % otool -L /Library/Frameworks/Tcl.framework/Tcl
     /Library/Frameworks/Tcl.framework/Tcl:
	    /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl (compatibility  
version 8.4.0, current version 8.4.0)
	    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current  
version 63.0.0)
	     
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/ 
CoreFoundation (compatibility version 150.0.0, current version 263.5.0)

     % otool -L /Library/Frameworks/Tk.framework/Tk
     /Library/Frameworks/Tk.framework/Tk:
	    /Library/Frameworks/Tk.framework/Versions/8.4/Tk (compatibility  
version 8.4.0, current version 8.4.0)
	    /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl (compatibility  
version 8.4.0, current version 8.4.0)
	    /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon  
(compatibility version 2.0.0, current version 122.0.0)
	     
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ 
ApplicationServices (compatibility version 1.0.0, current version  
18.0.0)
	    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current  
version 63.0.0)

on your machine?

Also, I've found in some instances that it is better to softlink the  
dir Tcl.framework/Versions/8.4 or even its contents to the  
corresponding directory in your real framework, and replicate the rest  
of the structure in Tcl.framework manually e.g. like so

     % ls -lR Tcl.framework
     total 40
     lrwxrwxrwx  1 steffen  staff   24 Nov  6 04:42 Headers ->  
Versions/Current/Headers
     lrwxrwxrwx  1 steffen  staff   31 Nov  6 04:42 PrivateHeaders ->  
Versions/Current/PrivateHeaders
     lrwxrwxrwx  1 steffen  staff   26 Nov  6 04:42 Resources ->  
Versions/Current/Resources
     lrwxrwxrwx  1 steffen  staff   20 Nov  6 04:42 Tcl ->  
Versions/Current/Tcl
     lrwxrwxrwx  1 steffen  staff   26 Nov  6 04:42 Tcl_debug ->  
Versions/Current/Tcl_debug
     drwxr-xr-x  4 steffen  staff  136 Nov  6 04:41 Versions

     Tcl.framework/Versions:
     total 8
     drwxr-xr-x  10 steffen  staff  340 Nov  6 04:41 8.4
     lrwxr-xr-x   1 steffen  staff    3 Nov  6 04:41 Current -> 8.4

     Tcl.framework/Versions/8.4:
     total 64
     lrwxr-xr-x  1 steffen  staff  54 Nov  6 04:41 Headers ->  
/Library/Frameworks/Tcl.framework/Versions/8.4/Headers
     lrwxr-xr-x  1 steffen  staff  61 Nov  6 04:41 PrivateHeaders ->  
/Library/Frameworks/Tcl.framework/Versions/8.4/PrivateHeaders
     lrwxr-xr-x  1 steffen  staff  56 Nov  6 04:41 Resources ->  
/Library/Frameworks/Tcl.framework/Versions/8.4/Resources
     lrwxr-xr-x  1 steffen  staff  56 Nov  6 04:41 Tcl ->  
/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl_debug
     lrwxr-xr-x  1 steffen  staff  56 Nov  6 04:41 Tcl_debug ->  
/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl_debug
     lrwxr-xr-x  1 steffen  staff  62 Nov  6 04:41 libtclstub8.4.a ->  
/Library/Frameworks/Tcl.framework/Versions/8.4/libtclstub8.4.a
     lrwxr-xr-x  1 steffen  staff  63 Nov  6 04:41 libtclstub8.4g.a ->  
/Library/Frameworks/Tcl.framework/Versions/8.4/libtclstub8.4g.a
     lrwxr-xr-x  1 steffen  staff  59 Nov  6 04:41 tclConfig.sh ->  
/Library/Frameworks/Tcl.framework/Versions/8.4/tclConfig.sh

note the link of Tcl to  
/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl_debug, you wouldn't  
want to do this in general.

by placing a Tcl.framework shell as above next to a binary you debug in  
Xcode, the debugging tcl library will be used automatically when  
debugging from Xcode (because DYLD_FRAMWORK_PATHS=`pwd`)

Cheers,

Daniel

-- 
** Daniel A. Steffen     **  "And now for something completely
** Dept. of Mathematics  **   different"    Monty Python
** Macquarie University  **  <mailto:steffen@...>
** NSW 2109 Australia    **  <http://www.maths.mq.edu.au/~steffen/>

Am 03.12.2003 um 20:24 schrieb Jim Ingham:

> How you get to Tcl.framework isn't really important, I think.  The 
> important point is whether the Tcl file inside the Tcl.framework is an 
> actual file or a link to the one in Versions/8.4.  The problem is that 
> depending on how you happen to link to things, you can get the actual 
> load command in the binary that links to Tcl to either be 
> Tcl.framework/Tcl OR Tcl.framework/Versions/8.4/Tcl (or what seems to 
> be the case for you, to BOTH).  Normally, it doesn't matter how you 
> record the path to the file, since the linker resolves file system 
> links and is smart enough to know that the two are actually the same 
> file.  But if they aren't the same file, then the linker will bring in 
> two copies of the Tcl library, and you will get link errors.

There's actually only one file "Tcl" which resides in 
"/System/Library/Frameworks/Tcl.framework/Versions/8.4/" - in several 
different places (like "/System/Library/Frameworks/Tcl.framework/" and 
"/Library/Frameworks/Tcl.framework/") there are links which resolve to 
that.

Phil

Am 04.12.2003 um 01:30 schrieb Daniel A. Steffen:

> Philipp,
>
> On Thursday, Dec 4, 2003, at 06:05 Australia/Sydney, Philipp Roessler  
> wrote:
>
>> Actually, "/Library/Frameworks/Tcl.framework" is a symbolic link to   
>> "System/Library/Frameworks/Tcl.framework".
>> I never had a real Tcl.framework lying in /Library/Frameworks/, only  
>> soft links. Before Panther this pointed to a Tcl.framework residing  
>> in my home directory (in fact this is where the my Tk.framework  
>> lies).
>
> so which Tcl.framework is Tk.framework linked to?
>
> can you give us the results of

To me my results of 'otool' look rather similar to yours:

; otool -L /Library/Frameworks/Tcl.framework/Tcl
/Library/Frameworks/Tcl.framework/Tcl:
         /System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl  
(compatibility version 8.4.0, current version 8.4.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
current version 71.0.0)
          
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/ 
CoreFoundation (compatibility version 150.0.0, current version 296.0.0)
; otool -L /Library/Frameworks/Tk.framework/Tk
/Library/Frameworks/Tk.framework/Tk:
         /Library/Frameworks/Tk.framework/Versions/8.4/Tk (compatibility  
version 8.4.0, current version 8.4.0)
         /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl  
(compatibility version 8.4.0, current version 8.4.0)
         /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon  
(compatibility version 2.0.0, current version 122.0.0)
          
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ 
ApplicationServices (compatibility version 1.0.0, current version  
18.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
current version 63.0.0)


> Also, I've found in some instances that it is better to softlink the  
> dir Tcl.framework/Versions/8.4 or even its contents to the  
> corresponding directory in your real framework, and replicate the rest  
> of the structure in Tcl.framework manually e.g. like so
>
>     % ls -lR Tcl.framework
>     total 40
>     lrwxrwxrwx  1 steffen  staff   24 Nov  6 04:42 Headers ->  
> Versions/Current/Headers
>     lrwxrwxrwx  1 steffen  staff   31 Nov  6 04:42 PrivateHeaders ->  
> Versions/Current/PrivateHeaders
>     lrwxrwxrwx  1 steffen  staff   26 Nov  6 04:42 Resources ->  
> Versions/Current/Resources
>     lrwxrwxrwx  1 steffen  staff   20 Nov  6 04:42 Tcl ->  
> Versions/Current/Tcl
>     lrwxrwxrwx  1 steffen  staff   26 Nov  6 04:42 Tcl_debug ->  
> Versions/Current/Tcl_debug
>     drwxr-xr-x  4 steffen  staff  136 Nov  6 04:41 Versions
>
>     Tcl.framework/Versions:
>     total 8
>     drwxr-xr-x  10 steffen  staff  340 Nov  6 04:41 8.4
>     lrwxr-xr-x   1 steffen  staff    3 Nov  6 04:41 Current -> 8.4
>
>     Tcl.framework/Versions/8.4:
>     total 64
>     lrwxr-xr-x  1 steffen  staff  54 Nov  6 04:41 Headers ->  
> /Library/Frameworks/Tcl.framework/Versions/8.4/Headers
>     lrwxr-xr-x  1 steffen  staff  61 Nov  6 04:41 PrivateHeaders ->  
> /Library/Frameworks/Tcl.framework/Versions/8.4/PrivateHeaders
>     lrwxr-xr-x  1 steffen  staff  56 Nov  6 04:41 Resources ->  
> /Library/Frameworks/Tcl.framework/Versions/8.4/Resources
>     lrwxr-xr-x  1 steffen  staff  56 Nov  6 04:41 Tcl ->  
> /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl_debug
>     lrwxr-xr-x  1 steffen  staff  56 Nov  6 04:41 Tcl_debug ->  
> /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl_debug
>     lrwxr-xr-x  1 steffen  staff  62 Nov  6 04:41 libtclstub8.4.a ->  
> /Library/Frameworks/Tcl.framework/Versions/8.4/libtclstub8.4.a
>     lrwxr-xr-x  1 steffen  staff  63 Nov  6 04:41 libtclstub8.4g.a ->  
> /Library/Frameworks/Tcl.framework/Versions/8.4/libtclstub8.4g.a
>     lrwxr-xr-x  1 steffen  staff  59 Nov  6 04:41 tclConfig.sh ->  
> /Library/Frameworks/Tcl.framework/Versions/8.4/tclConfig.sh

I did like you meant - but no change =(  Still the same linker output.

Phil

Try passing the "-t" and "-v" options to the linker.  These will get 
the linker to spit out all the files that it is loading as it loads 
them.  Then you should be able to see why Tcl is getting loaded twice, 
and who brought in each copy.

Jim

On Dec 3, 2003, at 11:05 AM, Philipp Roessler wrote:

>> From your snippet, I note:
>>
>>
>>> /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl(tclIOUtil.o) 
>>> definition of _TclFSSetPathDetails
>>> /Library/Frameworks/Tcl.framework/Tcl(tclIOUtil.o) definition of 
>>> _TclFSSetPathDetails
>>>
>>
>> The multiply defined symbols are not between the tcl framework & the 
>> tcl dylib anymore.  They are between two versions of the Tcl library 
>> WITHIN the Tcl framework...
>>
>> /Library/Frameworks/Tcl.framework/Tcl should be a LINK to 
>> /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl.
>
> Actually, "/Library/Frameworks/Tcl.framework" is a symbolic link to  
> "System/Library/Frameworks/Tcl.framework".
> I never had a real Tcl.framework lying in /Library/Frameworks/, only 
> soft links. Before Panther this pointed to a Tcl.framework residing in 
> my home directory (in fact this is where the my Tk.framework lies).
>
> Phil
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Tcl-mac mailing list
> Tcl-mac@...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>
--
Jim Ingham                                   jingham@...
Developer Tools
Apple Computer

Am 04.12.2003 um 19:58 schrieb Jim Ingham:

> Try passing the "-t" and "-v" options to the linker.  These will get 
> the linker to spit out all the files that it is loading as it loads 
> them.  Then you should be able to see why Tcl is getting loaded twice, 
> and who brought in each copy.
>
> Jim

That was interesting: looking at the output I remembered also what 
Benjamin said and tried to link like this:

 > g++ -framework Tk -o Invert ../tclbuf.o ../Image/Image.o 
../Image/TkRGBImage.o ../Filter/Invert.o main.o -lstdc++

(left out "- framework Tcl")
which only led to this:

"ld: ../tclbuf.o illegal reference to symbol: _TclFreeObj defined in 
indirectly referenced dynamic library 
/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl
child process exited abnormally" .

Looks better than 600+ lines of warnings - but still doesn't do the job.

Phil


> On Dec 3, 2003, at 11:05 AM, Philipp Roessler wrote:
>
>>> From your snippet, I note:
>>>
>>>
>>>> /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl(tclIOUtil.o) 
>>>> definition of _TclFSSetPathDetails
>>>> /Library/Frameworks/Tcl.framework/Tcl(tclIOUtil.o) definition of 
>>>> _TclFSSetPathDetails
>>>>
>>>
>>> The multiply defined symbols are not between the tcl framework & the 
>>> tcl dylib anymore.  They are between two versions of the Tcl library 
>>> WITHIN the Tcl framework...
>>>
>>> /Library/Frameworks/Tcl.framework/Tcl should be a LINK to 
>>> /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl.
>>
>> Actually, "/Library/Frameworks/Tcl.framework" is a symbolic link to  
>> "System/Library/Frameworks/Tcl.framework".
>> I never had a real Tcl.framework lying in /Library/Frameworks/, only 
>> soft links. Before Panther this pointed to a Tcl.framework residing 
>> in my home directory (in fact this is where the my Tk.framework 
>> lies).
>>
>> Phil
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: SF.net Giveback Program.
>> Does SourceForge.net help you be more productive?  Does it
>> help you create better code?  SHARE THE LOVE, and help us help
>> YOU!  Click Here: http://sourceforge.net/donate/
>> _______________________________________________
>> Tcl-mac mailing list
>> Tcl-mac@...
>> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>>
> --
> Jim Ingham                                   jingham@...
> Developer Tools
> Apple Computer
>

I've run into a problem that I can't seem to make go away.  We build our
application and link against our own version of the tcl/tk libs (and
itcl/itk/iwidgets).  If I give -L path options to our built tcl lib and
-ltcl8.4, it still links against the system tcl lib (same goes for the
others too that are present).  In 10.2, our hack workaround was to simply
move /usr/lib/libt(cl|k)* out of the way when building (the app was linked
staticly) and all was fine.

I'm trying to solve the problem for 10.3 and am having difficulties even
when using the -nodefaultlibs option, and while building shared libraries
eventually (but can't even get static to work right still).  Any ideas?

Here is a typical link line for our own version of wish:

cc -o bwish -nodefaultlibs -lc -lgcc main.o input.o tcl.o cmd.o
-L''../.libfb.pmac -lfb -L''../.libpkg.pmac -lpkg -L''../.libwdb.pmac
-lwdb -L''../.librt.pmac -lrt -L''../.libbn.pmac -lbn -L''../.libbu.pmac
-lbu -L''../.libtcl''8.4.''pmac -ltcl''8.4
-L''../.libitcl''3.2.''pmac/itcl -litcl''3.2 -L''../.libtermio.pmac
-ltermio -L''../.libdm.pmac -ldm -L''../.libtk''8.4.''pmac -ltk''8.4
-L''../.libtcl''8.4.''pmac -ltcl''8.4 -L''../.libitcl''3.2.''pmac/itk
-litk''3.2 -L''../.libitcl''3.2.''pmac/itcl -litcl''3.2 -L''/usr/X11R6/lib
-lXi -L''../.libfb.pmac -lfb -L''../.libpkg.pmac -lpkg -L''/usr/X11R6/lib
-lX11 -lXi -lXext -L''../.libtclcad.pmac -ltclcad -L''../.libsysv.pmac
-lsysv -lm -lc -framework Foundation vers.o

Here's a one such runtime error for wish:

morrison$ /usr/brlcad/bin/bwish
Application initialization failed: Can't find a usable tk.tcl in the
following directories:
    /System/Library/Frameworks/Tcl.framework/Versions/8.4/Resources/tk8.4
/usr/brlcad/lib/tk8.4 /usr/lib/tk8.4 /usr/brlcad/library /usr/library
/usr/tk8.4.4/library /tk8.4.4/library
/System/Library/Frameworks/Tcl.framework/Versions/8.4/Resources/Scripts/tk8.4
/System/Library/Frameworks/Tcl.framework/Versions/8.4/Resources/Scripts/tk8.4/Resources/Scripts
~/Library/Tcl/tk8.4 ~/Library/Tcl/tk8.4/Resources/Scripts
/Library/Tcl/tk8.4 /Library/Tcl/tk8.4/Resources/Scripts
/Network/Library/Tcl/tk8.4 /Network/Library/Tcl/tk8.4/Resources/Scripts
/System/Library/Tcl/tk8.4 /System/Library/Tcl/tk8.4/Resources/Scripts
~/Library/Frameworks/tk8.4 ~/Library/Frameworks/tk8.4/Resources/Scripts
/Library/Frameworks/tk8.4 /Library/Frameworks/tk8.4/Resources/Scripts
/Network/Library/Frameworks/tk8.4
/Network/Library/Frameworks/tk8.4/Resources/Scripts
/System/Library/Frameworks/tk8.4
/System/Library/Frameworks/tk8.4/Resources/Scripts

This leads me to think that the link succeeds, but something else is still
awry.  The tk.tcl file in question is at /usr/brlcad/lib/tk8.4/tk.tcl
where it supposedly is looking.  Further curious is that if I export
the correct values for TK_LIBRARY, TCL_LIBRARY, etc and move iwidgets into
itcl, everything works.  Any insights?

Cheers!
Sean


On Tue, 2 Dec 2003, Jim Ingham wrote:

> Can you send us your exact newly failing command-line (plus error
> message).  If you don't say -ltcl8.4, the linker shouldn't be picking
> up the version of tcl in /usr/lib.
>
> Jim

It looks like the link is succeeding, but you will know for sure if you  
do:


$ setenv DYLD_PRINT_LIBRARIES 1
$ /usr/brlcad/bin/bwish

and watch the output.  That will tell you which version of the Tcl & Tk  
libraries actually got loaded.

The immediate error is that Tcl & Tk don't know where to look for the  
script files.  Where is the tk.tcl that you want Wish to find?

If you are building a Unix/X11 version of Tcl & Tk (as opposed to using  
Mac OS X style frameworks) you tell Tcl where it is going to find these  
script files by passing --prefix=/install/root whatever the install  
root is to configure.  That will get the build system to seed the  
library search path with the correct  install location.  Are you doing  
that?

Jim

On Jan 13, 2004, at 2:23 PM, Christopher Sean Morrison wrote:

>
> I've run into a problem that I can't seem to make go away.  We build  
> our
> application and link against our own version of the tcl/tk libs (and
> itcl/itk/iwidgets).  If I give -L path options to our built tcl lib and
> -ltcl8.4, it still links against the system tcl lib (same goes for the
> others too that are present).  In 10.2, our hack workaround was to  
> simply
> move /usr/lib/libt(cl|k)* out of the way when building (the app was  
> linked
> staticly) and all was fine.
>
> I'm trying to solve the problem for 10.3 and am having difficulties  
> even
> when using the -nodefaultlibs option, and while building shared  
> libraries
> eventually (but can't even get static to work right still).  Any ideas?
>
> Here is a typical link line for our own version of wish:
>
> cc -o bwish -nodefaultlibs -lc -lgcc main.o input.o tcl.o cmd.o
> -L''../.libfb.pmac -lfb -L''../.libpkg.pmac -lpkg -L''../.libwdb.pmac
> -lwdb -L''../.librt.pmac -lrt -L''../.libbn.pmac -lbn  
> -L''../.libbu.pmac
> -lbu -L''../.libtcl''8.4.''pmac -ltcl''8.4
> -L''../.libitcl''3.2.''pmac/itcl -litcl''3.2 -L''../.libtermio.pmac
> -ltermio -L''../.libdm.pmac -ldm -L''../.libtk''8.4.''pmac -ltk''8.4
> -L''../.libtcl''8.4.''pmac -ltcl''8.4 -L''../.libitcl''3.2.''pmac/itk
> -litk''3.2 -L''../.libitcl''3.2.''pmac/itcl -litcl''3.2  
> -L''/usr/X11R6/lib
> -lXi -L''../.libfb.pmac -lfb -L''../.libpkg.pmac -lpkg  
> -L''/usr/X11R6/lib
> -lX11 -lXi -lXext -L''../.libtclcad.pmac -ltclcad -L''../.libsysv.pmac
> -lsysv -lm -lc -framework Foundation vers.o
>
> Here's a one such runtime error for wish:
>
> morrison$ /usr/brlcad/bin/bwish
> Application initialization failed: Can't find a usable tk.tcl in the
> following directories:
>      
> /System/Library/Frameworks/Tcl.framework/Versions/8.4/Resources/tk8.4
> /usr/brlcad/lib/tk8.4 /usr/lib/tk8.4 /usr/brlcad/library /usr/library
> /usr/tk8.4.4/library /tk8.4.4/library
> /System/Library/Frameworks/Tcl.framework/Versions/8.4/Resources/ 
> Scripts/tk8.4
> /System/Library/Frameworks/Tcl.framework/Versions/8.4/Resources/ 
> Scripts/tk8.4/Resources/Scripts
> ~/Library/Tcl/tk8.4 ~/Library/Tcl/tk8.4/Resources/Scripts
> /Library/Tcl/tk8.4 /Library/Tcl/tk8.4/Resources/Scripts
> /Network/Library/Tcl/tk8.4 /Network/Library/Tcl/tk8.4/Resources/Scripts
> /System/Library/Tcl/tk8.4 /System/Library/Tcl/tk8.4/Resources/Scripts
> ~/Library/Frameworks/tk8.4 ~/Library/Frameworks/tk8.4/Resources/Scripts
> /Library/Frameworks/tk8.4 /Library/Frameworks/tk8.4/Resources/Scripts
> /Network/Library/Frameworks/tk8.4
> /Network/Library/Frameworks/tk8.4/Resources/Scripts
> /System/Library/Frameworks/tk8.4
> /System/Library/Frameworks/tk8.4/Resources/Scripts
>
> This leads me to think that the link succeeds, but something else is  
> still
> awry.  The tk.tcl file in question is at /usr/brlcad/lib/tk8.4/tk.tcl
> where it supposedly is looking.  Further curious is that if I export
> the correct values for TK_LIBRARY, TCL_LIBRARY, etc and move iwidgets  
> into
> itcl, everything works.  Any insights?
>
> Cheers!
> Sean
>
>
> On Tue, 2 Dec 2003, Jim Ingham wrote:
>
>> Can you send us your exact newly failing command-line (plus error
>> message).  If you don't say -ltcl8.4, the linker shouldn't be picking
>> up the version of tcl in /usr/lib.
>>
>> Jim
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Tcl-mac mailing list
> Tcl-mac@...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>
--
Jim Ingham                                   jingham@...
Developer Tools
Apple Computer

It's been a little while since my initial question, and I've done some
further poking with continued disdain.  To summarize, I've been facing a
problem where building tclsh incessintly builds against the mac os x
system tcl instead of using the libtcl that I build.  Regardless of
-nodefaultlibs, it seems to either ignore our -L option or give precedence
to the system tcl when searching for -ltcl8.4.

On Tue, 13 Jan 2004, Jim Ingham wrote:

> It looks like the link is succeeding, but you will know for sure if you
> do:
>
> $ setenv DYLD_PRINT_LIBRARIES 1
> $ /usr/brlcad/bin/bwish
>
> and watch the output.  That will tell you which version of the Tcl & Tk
> libraries actually got loaded.

Thanks for this tip.  It was useful, and indeed confirmed that the system
tcl was getting in the way:

[static build of libtcl8.4.a performed here]
cc -pipe -prebind  tclAppInit.o -L/vld/morrison/brlcad/.libtcl8.4.pmac -ltcl8.4 -framework CoreFoundation -o tclsh
./tclsh
loading libraries for image: ./tclsh
loading library: /System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl
loading library: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
loading library: /usr/lib/libSystem.B.dylib
...

If I relink using the .a directly, it links how I'd expect it to:

cc -pipe -prebind  tclAppInit.o ./libtcl8.4.a -framework CoreFoundation -o tclsh
./tclsh
loading libraries for image: ./tclsh
loading library: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
loading library: /usr/lib/libSystem.B.dylib
...

Again no link difference if I pass -nodefaultlibs or -nostdlib in.

> The immediate error is that Tcl & Tk don't know where to look for the
> script files.  Where is the tk.tcl that you want Wish to find?

They are in the --prefix dir at "prefix"/lib/tk8.4 for tk and
"prefix"/lib/tcl8.4 for tcl.  ("prefix" is /usr/brlcad in this particular
example)

> If you are building a Unix/X11 version of Tcl & Tk (as opposed to using
> Mac OS X style frameworks) you tell Tcl where it is going to find these
> script files by passing --prefix=/install/root whatever the install
> root is to configure.  That will get the build system to seed the
> library search path with the correct  install location.  Are you doing
> that?

We are indeed building using the unix version/style presently for mac os
x.  We pass --prefix to the right place, and again the problem appears to
be that when the tclsh binary itself is linked, that it's linked against
the existing system Tcl instead of what was just compiled.  Here's our
configure line:

../libtcl8.4/unix/configure
--srcdir=/vld/morrison/brlcad/.libtcl8.4.pmac/unix --quiet --cache-file
cache.pmac --exec-prefix=/usr/brlcad --prefix=/usr/brlcad --disable-shared

As you can see, we are doing a static build there, which may be part of
the problem with how the linker searches.

I've found what appears to be some hint of a solution, but the cause of
the problem remains elusive.

Basically, I've narrowed the problem down to a case where if I build
tclsh (for example) and link tclsh using -Lyadayada -ltcl8.4 that it does
not use my yadayada path.  It links against the system framework of
/System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl.

If I instead simply link against the static libtcl archive that I just
built using ./libtcl8.5.a instead of -Lyadayada -ltcl8.4, then it of
course properly links -- as was shown up above.

This behavior seems contrary to all our other supported unix platforms, so
I'm doing my best to assume that I'm missing some fundamental piece of the
puzzle or perhaps apple's modified gcc is doing something that I'm not
expecting search-path-wise.  Any insight or correction slaps are more than
welcome.

Cheers!
Sean

p.s. On another note, we were using 8.4.4 when I first started hunting
this problem, and I'm upgrading to 8.4.6 now just because we should.

Sean,

On Friday, Mar 5, 2004, at 02:21 Australia/Sydney, Christopher Sean 
Morrison wrote:

> ../libtcl8.4/unix/configure
> --srcdir=/vld/morrison/brlcad/.libtcl8.4.pmac/unix --quiet --cache-file
> cache.pmac --exec-prefix=/usr/brlcad --prefix=/usr/brlcad 
> --disable-shared
>
> As you can see, we are doing a static build there, which may be part of
> the problem with how the linker searches.

this is exactly the crucial point, I hadn't realized your were linking 
statically in your previous question

what you're seeing is a (mis)feature of the Darwin ld in that when 
searching for a library in response to -lblah it always prefers a 
dynamic library libblah.dylib instead of a static one libblah.a if it 
can find such a dynamic library anywhere on its search path.

I presume you're working on Panther, and /usr/lib/libtcl.dylib or 
/usr/lib/libtcl8.4.dylib are thus getting in the way of -ltcl finding 
your static version. Since these are just symlinks to 
/System/Libray/Frameworks/Tcl.framework/Tcl, one way to workaround the 
problem is just to temporarily move these symlinks aside, the system 
tcl will not break as a result of that (but building other tcl software 
might, of course).

The way to tell ld that you want a specific static library to be used 
while linking is to give the full path to the .a library on the link 
line instead of using the -l option, but that will require makefile 
fiddling of course...

See the darwin-development list archives for more details & background 
on the ld & static libs issue, it has come up there quite a few times

Cheers,

Daniel

-- 
** Daniel A. Steffen     **  "And now for something completely
** Dept. of Mathematics  **   different"    Monty Python
** Macquarie University  **  <mailto:steffen@...>
** NSW 2109 Australia    **  <http://www.maths.mq.edu.au/~steffen/>

Daniel,

Ugh.  I had feared something along those lines was happening with the
static libs.  Thank you in any respect, however, for the explanation.

Since it wouldn't be prudent for out team to assume that our users will be
able to move their system libraries out of the way (like we had been doing
ourselves), I think our best solution is to simply rename the library for
static builds so as not to collide with the system tcl library name.  I
assume that dynamic library search path ordering is "doing the right
thing" and won't need to be modified, though I'll have to now reverify
this for just for my own sanity.

Now to figure out why linking with AquaTk crashes.. ;)

Cheers!
Sean


On Fri, 5 Mar 2004, Daniel A. Steffen wrote:

> [snip snip]
>
> this is exactly the crucial point, I hadn't realized your were linking
> statically in your previous question
>
> what you're seeing is a (mis)feature of the Darwin ld in that when
> searching for a library in response to -lblah it always prefers a
> dynamic library libblah.dylib instead of a static one libblah.a if it
> can find such a dynamic library anywhere on its search path.
>
> I presume you're working on Panther, and /usr/lib/libtcl.dylib or
> /usr/lib/libtcl8.4.dylib are thus getting in the way of -ltcl finding
> your static version. Since these are just symlinks to
> /System/Libray/Frameworks/Tcl.framework/Tcl, one way to workaround the
> problem is just to temporarily move these symlinks aside, the system
> tcl will not break as a result of that (but building other tcl software
> might, of course).
>
> The way to tell ld that you want a specific static library to be used
> while linking is to give the full path to the .a library on the link
> line instead of using the -l option, but that will require makefile
> fiddling of course...
>
> See the darwin-development list archives for more details & background
> on the ld & static libs issue, it has come up there quite a few times
>
> Cheers,
>
> Daniel