Using the XCode tools on Mac OSX to compile tcl/tk 8.5.5 C application ...
lefty
I've compiled and linked 8.5.5 on Mac OS X 10.4.11 using the Xcode
tools as provided by the OS, and that all went just fine and dandy. I
can bring up the tclsh8.5, and puts $tcl_patchLevel tells me that I've
arrived, likewise with wish8.5 reporting a tcl_patchLevel of 8.5.5 as
well, and it works OK.
My problem is linking a trivial C application which creates a single
ttk::button which links and runs just fine on FreeBSD (various), and
Linux (32 bit and 64 bit), as well as Windows. I cannot for the life
of me find either the libtk8.5.dylib or libtk8.5.a file on that
platform, and so I cannot figure out how to link my application.
In looking through the config.log file, I see somewhere the TK_LIB is
set to -lTk, rather than -ltk8.5. Using that, I actually link my
application, and get a runnable executable, which immediately dies
when it attempts to start Tk up, and I'm thinking that I might have
linked with the wrong library (bad memory access) 8-{.
In general, one might figure that the library would be located within
the tree which is defined by --prefix on the configure script. I've
let it default, and I've specified it as well, but thus far, the
libtk8.5.so beastie has eluded me.
You've probably figured by now I'm a relative newbie to Mac
development, but once I get through this hurdle, I expect that the
combination of C and tcl/tk will make it appear as though I know what
I'm doing (heh heh).
The stack dump from gdb is:
tst:~/sw/New/UnitTests rob$ gdb gui
GNU gdb 6.1-20040303 (Apple version gdb-437) (Fri Jan 13 18:45:48 GMT
2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for
shared libraries .... done
(gdb) run
Starting program: /Users/rob/sw/New/UnitTests/gui
Reading symbols for shared
libraries .....................................................................
done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x141b0680
0x9b7577f4 in TclpFree ()
(gdb) bt
#0 0x9b7577f4 in TclpFree ()
#1 0x9b7538f7 in ResetObjResult ()
#2 0x9b753e1c in Tcl_AppendResultVA ()
#3 0x9b753f70 in Tcl_AppendResult ()
#4 0x9b74f327 in Tcl_PkgRequireEx ()
#5 0x9b74f362 in Tcl_PkgRequire ()
#6 0x9b7d802a in Tk_MainEx ()
#7 0x00001b90 in Gui (argc=1, argv=0xbffffca8) at Src/gui.c:8
#8 0x00001b22 in main (argc=1, argv=0xbffffca8) at gui.c:5
(gdb)
Any pointers on this would be much appreciated ...
Kevin Walzer
Sounds like it might be a conflict between your own instllation of
Tcl/Tk and the version that comes installed with OS X 10.4 (Tcl/Tk
8.4.7, installed in /System/Library).
http://wiki.tcl.tk/12987 and http://wiki.tcl.tk/12935 might be good
pages to review--they have a lot of information on Tcl/Tk on the Mac,
including how to link to it.
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
lefty
> pages to review--they have a lot of information on Tcl/Tk on the Mac,
> including how to link to it.
>
> --
> Kevin Walzer
> Code by Kevinhttp://www.codebykevin.com
AHA!
Thanks for the link!!!!
I have to get to my other office to try this, but it appears that the
following
is perhaps the key to solving my woes, and has the elegant simplicity
of a
'correct answer':
gcc -dynamiclib -o yourlib.dylib yourcommands.o \
-framework Tcl -framework Tk
Kevin, do you know how to further specify the 8.5(.5) release rather
than the default 8.4 using
the -framework syntax, I'd be much obliged? As indicated, I have
successfully built and
installed the 8.5.5, and it appears that there is an 8.5 framework now
in place in the Library
path ...
Cheers,
Rob.
Daniel A. Steffen
On Dec 8, 5:04 pm, lefty <rsc...@ica.net> wrote:
> On Dec 8, 10:22 am, Kevin Walzer <k...@codebykevin.com> wrote:
> > lefty wrote:
> > > I've compiled and linked 8.5.5 on Mac OS X 10.4.11 using the Xcode
> > > tools as provided by the OS, and that all went just fine and dandy.
which buildsystem are you using, the Xcode projects in macosx, the
macosx/GNUMakefile or the unix configure & make ?
all three are possibilities (with increasing complexity but also
flexibility), c.f. macosx/README for (some) details
> > > I can bring up the tclsh8.5, and puts $tcl_patchLevel tells me that I've
> > > arrived, likewise with wish8.5 reporting a tcl_patchLevel of 8.5.5 as
> > > well, and it works OK.
you do not say how you bring up tclsh8.5/wish8.5, from inside Xcode
after a build? or from the cli after a make install?
if this is from Xcode, it sets up the right DYLD_* env vars for you
that point to the build products location to ensure that the just
built dynamic libraries are found... (e.g. look at the output of
[parray env] in the tclsh8.5 that comes up)
> > > My problem is linking a trivial C application which creates a single
> > > ttk::button which links and runs just fine on FreeBSD (various), and
> > > Linux (32 bit and 64 bit), as well as Windows. I cannot for the life
> > > of me find either the libtk8.5.dylib or libtk8.5.a file on that
> > > platform, and so I cannot figure out how to link my application.
the default for the Xcode & macosx buildsystems is to build Tcl/Tk as
frameworks, but the standard unix style of dylibs installed in $prefix/
lib is also available if you use the unix configure/make buildsystem
(omit the --enable-framework configure flag)
> > > In looking through the config.log file, I see somewhere the TK_LIB is
> > > set to -lTk, rather than -ltk8.5. Using that, I actually link my
> > > application, and get a runnable executable, which immediately dies
> > > when it attempts to start Tk up, and I'm thinking that I might have
> > > linked with the wrong library (bad memory access) 8-{.
the easiest way to figure out which library is actually getting loaded
at runtime is to set the DYLD_PRINT_LIBRARIES env var, c.f. man dyld
> > > In general, one might figure that the library would be located within
> > > the tree which is defined by --prefix on the configure script. I've
> > > let it default, and I've specified it as well, but thus far, the
> > > libtk8.5.so beastie has eluded me.
usually a MachO binary has the full (install-)path to the dynamic
libraries it depends on embedded (c.f. otool -L myexe), and there are
DYLD_* environment variables to set the search path if a library is
not found at the embedded location, c.f. man dydl & man ld
> I have to get to my other office to try this, but it appears that the
> following
> is perhaps the key to solving my woes, and has the elegant simplicity
> of a
> 'correct answer':
>
> gcc -dynamiclib -o yourlib.dylib yourcommands.o \
> -framework Tcl -framework Tk
I'd recommend a build process that reads and uses the linker options
contained in tclConfig.sh resp. tkConfig.sh (e.g. TK_LIB_SPEC), that
way you are insulated from any platform or configuration differences
(e.g. things will work both with --enable-framework and --disable-
framework builds on OS X)
also, if yourlib.dylib is in fact a tcl extension (as opposed to a tcl
embedder), it would be much easier to use stub linking (c.f. wiki),
that way the whole issue of finding the right tcl resp tk dynamic
library at runtime goes away for your dylib...
> Kevin, do you know how to further specify the 8.5(.5) release rather
> than the default 8.4 using
> the -framework syntax, I'd be much obliged? As indicated, I have
> successfully built and
> installed the 8.5.5, and it appears that there is an 8.5 framework now
> in place in the Library
> path ...
gcc and ld have search paths for frameworks that are distinct from
library search paths, you can add to them via the -F flag, c.f. man
gcc & man ld
the first framework that is found on that search path is used, so if
you install your framework e.g. in /Library/Frameworks, it will be
found before the system provided one in /System/Library/Frameworks
note that the search paths at runtime may be different, i.e. you can
link against one framework at build time and get dynamically linked
against another one at runtime (which may be what is happening in your
case)
if you use the standard system locations like /Library/Frameworks and
~/Library/Frameworks this is usually not an issue, otherwise you may
have to configure your DYLD_FRAMEWORK_PATH env variable, again c.f.
man dyld.
HTH
Cheers,
Daniel
lefty
wrote:
Daniel,
Thanks for the information. Indeed, I used a ../configure ; make from
a new subdirectory in the macosx subdir. In general, on a given
platform, I'll create either a unix/build or a win/build (macosx/
build) subdir, and by habit will do ../configure then make.
I think your tclConfig.sh is probably the best way to go, and I'll
look to re-writing my makefile to use this
approach. I alreach use the Apache Portable Runtime, and the config
(apr-1-config) tool there in the makefile, so moving to the
tclConfig.sh approach is a natural, and correct one.
Having to learn a bit about Frameworks and the Mac way of doing things
is not a bad thing, and in truth, being a big FreeBSD fan, the shell
window on a mac feels pretty familiar. That being said, my Makefile
needs work, and I will incorporate the suggestions provided here.
Meanwhile, thanks for all the help!!!
Cheers,
Rob.
lefty
Thanks for all the very good information. I went back to the Mac, and
simply changed the LDOPTS to -framework tcl -framework tk, and linking
worked just fine, as did the application. I will still re-work my
Makefile to be more robust, and platform independent, but
for now, it appears that at least I can build and link C apps to Tk
8.5.5 (using ttk), and I appreciate not only the acute info, but the
large amount of background and relevant info to help me on my way.
Cheers,
Rob.