Menu
▾
▴
tktable-tile-dev
|
From: Kevin W. <sw...@wo...> - 2005-09-28 23:14:17
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've done a bit more investigating on building Tile as a universal binary on OS X. It seems like an issue with TkAqua rather than Tile, because I'm seeing the same issues trying to build another extension (tktreectrl) as a universal binary. Earlier, the build was dying after complaining that some defintions in tkMacOSXInt.h had errors. Looking at the code in question, I noticed that the lines began with the phrase "Module Scope," like this: ~ MODULE_SCOPE int TkMacOSXUseAntialiasedText(Tcl_Interp *interp, int enable); Commenting out those lines and replacing them without the phrase "module scope" allowed the build to proceed, and I built Tile and Tktreectrl successfully in the standard fashion (not as universal binaries). I'm not sure why commenting out the "module scope" bits worked; I'm sure that is there for a reason, but it's not clear to me. Trying again as a universal binary (building against the 10.4 sdk, -arch i386, -arch ppc, and so on), Tile (and tktreectrl) got all the way through the builds before dying with this error message: ld: Undefined symbols: _tclStubsPtr _Tcl_InitStubs _Tk_InitStubs _tkStubsPtr _tkIntXlibStubsPtr _tkIntStubsPtr _tkIntPlatStubsPtr _tkPlatStubsPtr /usr/bin/libtool: internal link edit command failed lipo: can't figure out the architecture type of: /var/tmp//ccOMqrpA.out make: *** [libtile0.6.dylib] Error 1 I'm not sure where these symbols are supposed to come in: perhaps someone with more knowledge than me would find this error message useful? - -- Cheers, Kevin Walzer, PhD WordTech Software http://www.wordtech-software.com sw at wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDOyO8JmdQs+6YVcoRApRQAJ4kbS+SU/2G9+Kfnf7Ff1p1Xi60rgCdEotd 8FzsUwgQiZ+yvMbEdme+dR8= =2iMU -----END PGP SIGNATURE----- |
|
From: Joe E. <jen...@fl...> - 2005-09-29 00:07:30
|
Kevin Walzer wrote:
> I've done a bit more investigating on building Tile as a universal
> binary on OS X. It seems like an issue with TkAqua rather than Tile,
> because I'm seeing the same issues trying to build another extension
> (tktreectrl) as a universal binary.
> [...]
> Trying again as a universal binary (building against the 10.4 sdk, -arch
> i386, -arch ppc, and so on), Tile (and tktreectrl) got all the way
> through the builds before dying with this error message:
> ld: Undefined symbols:
> _tclStubsPtr
> _Tcl_InitStubs
> _Tk_InitStubs
> _tkStubsPtr
> _tkIntXlibStubsPtr
> _tkIntStubsPtr
> _tkIntPlatStubsPtr
> _tkPlatStubsPtr
> [...]
> I'm not sure where these symbols are supposed to come in: perhaps
> someone with more knowledge than me would find this error message useful?
That I can help with: all of the above come from the Tcl (resp Tk)
stubs libraries, {lib}{tcl|tk}stub{8.4|84|.8.4}.{a|lib}.
On OSX, IIRC, make sure the link line includes '-ltkstub8.4' and
'-ltclstub8.4'. Also make sure that libXXXstubX.Y.a appear in
the linker search path; if not, add "-L" flags and/or
"-framework Tcl" / "-framework Tk" flags to the link line.
Also: did you run "./configure ; make" in the top-level tile directory
or in tile/generic? Whichever one you tried and it didn't work,
try the other one and see if you have better luck. The top-level
build structure is "TEA-compliant" (meaning: works for Jeff);
the one in generic/ is "Modified TEA" (meaning: works for me).
Usually one or the other will eventually spit out a working
shared library if you kick it hard enough, but since neither
Jeff nor I have a Macintosh we can't make any guarantees. Sorry.
> Earlier, the build was dying after complaining that some defintions in
> tkMacOSXInt.h had errors. Looking at the code in question, I noticed
> that the lines began with the phrase "Module Scope," like this:
>
> ~ MODULE_SCOPE int TkMacOSXUseAntialiasedText(Tcl_Interp *interp, int
> enable);
That one I can't help with. I have a suspicion that the MODULE_SCOPE
macro is just a bad idea that will eventually be expunged, but don't
know all the details yet. Sorry.
--Joe English
|
|
From: Jeff H. <je...@Ac...> - 2005-09-29 00:26:29
|
Joe English wrote: > Kevin Walzer wrote: > > I've done a bit more investigating on building Tile as a universal > > binary on OS X. It seems like an issue with TkAqua rather than Tile, > > because I'm seeing the same issues trying to build another extension > > (tktreectrl) as a universal binary. ... > Also: did you run "./configure ; make" in the top-level tile > directory or in tile/generic? Whichever one you tried and it > didn't work, try the other one and see if you have better > luck. The top-level build structure is "TEA-compliant" > (meaning: works for Jeff); the one in generic/ is "Modified > TEA" (meaning: works for me). Usually one or the other will > eventually spit out a working shared library if you kick it > hard enough, but since neither Jeff nor I have a Macintosh we > can't make any guarantees. Sorry. I just want to note that I do have a Mac, but not a MacTel at this point. I do build treectrl and tile on it regularly, but I haven't made any attempts to do universal binaries yet. Jeff |
|
From: <lm...@bi...> - 2005-09-29 00:34:09
|
On Wed, Sep 28, 2005 at 05:23:01PM -0700, Jeff Hobbs wrote: > Joe English wrote: > > Kevin Walzer wrote: > > > I've done a bit more investigating on building Tile as a universal > > > binary on OS X. It seems like an issue with TkAqua rather than Tile, > > > because I'm seeing the same issues trying to build another extension > > > (tktreectrl) as a universal binary. > ... > > Also: did you run "./configure ; make" in the top-level tile > > directory or in tile/generic? Whichever one you tried and it > > didn't work, try the other one and see if you have better > > luck. The top-level build structure is "TEA-compliant" > > (meaning: works for Jeff); the one in generic/ is "Modified > > TEA" (meaning: works for me). Usually one or the other will > > eventually spit out a working shared library if you kick it > > hard enough, but since neither Jeff nor I have a Macintosh we > > can't make any guarantees. Sorry. > > I just want to note that I do have a Mac, but not a MacTel at > this point. I do build treectrl and tile on it regularly, > but I haven't made any attempts to do universal binaries yet. We have a MacTel and if we can help out let us know what you want. We don't have a lot of spare cycles but we're trying to do stuff on that box. We have found that unlink/stat are busted, Oscar can give you a pointer to bug report if you like. -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
|
From: Daniel A. S. <st...@ic...> - 2005-09-29 00:08:49
|
Kevin, On 29/09/2005, at 9:14, Kevin Walzer wrote: > Earlier, the build was dying after complaining that some defintions in > tkMacOSXInt.h had errors. Looking at the code in question, I noticed > that the lines began with the phrase "Module Scope," like this: > > ~ MODULE_SCOPE int TkMacOSXUseAntialiasedText(Tcl_Interp *interp, int > enable); > > Commenting out those lines and replacing them without the phrase > "module > scope" allowed the build to proceed, and I built Tile and Tktreectrl > successfully in the standard fashion (not as universal binaries). > > I'm not sure why commenting out the "module scope" bits worked; I'm > sure > that is there for a reason, but it's not clear to me. the problem is that MODULE_SCOPE is not defined in you build, it looks like this is probably a bug on my end, it should be defined in tkInt.h as it is in tclInt.h, in the meantime, including tclInt.h before tkMacOSXInt.h should fix the problem. As mentioned, you can't rely on using those routines in tile anyway, so maybe tkMacOSXInt.h shouldn't be included at all > Trying again as a universal binary (building against the 10.4 sdk, > -arch > i386, -arch ppc, and so on), Tile (and tktreectrl) got all the way > through the builds before dying with this error message: > > ld: Undefined symbols: > _tclStubsPtr > _Tcl_InitStubs > _Tk_InitStubs > _tkStubsPtr > _tkIntXlibStubsPtr > _tkIntStubsPtr > _tkIntPlatStubsPtr > _tkPlatStubsPtr > /usr/bin/libtool: internal link edit command failed > lipo: can't figure out the architecture type of: /var/tmp//ccOMqrpA.out > make: *** [libtile0.6.dylib] Error 1 > > I'm not sure where these symbols are supposed to come in: perhaps > someone with more knowledge than me would find this error message > useful? this means that linking with the tcl/tk stubs lib goes wrong somehwere as these symbols are all defined in libtclstub.a resp libtkstub.a. Are you sure you are linking against universal stubs libs ? make sure those libs got built fat as well (check with lipo -info), otherwise rebuild your tcl & tk Cheers, Daniel -- ** Daniel A. Steffen ** "And now for something completely ** Dept. of Mathematics ** different" Monty Python ** Macquarie University ** <mailto:st...@ma...> ** NSW 2109 Australia ** <http://www.maths.mq.edu.au/~steffen/> |
|
From: Donal K. F. <don...@ma...> - 2005-09-29 08:30:36
|
Kevin Walzer wrote: > Earlier, the build was dying after complaining that some defintions in > tkMacOSXInt.h had errors. Looking at the code in question, I noticed > that the lines began with the phrase "Module Scope," like this: > > ~ MODULE_SCOPE int TkMacOSXUseAntialiasedText(Tcl_Interp *interp, int > enable); > > Commenting out those lines and replacing them without the phrase "module > scope" allowed the build to proceed, and I built Tile and Tktreectrl > successfully in the standard fashion (not as universal binaries). OK, that might indicate that TkMacOSXUseAntialiasedText may need to be promoted from a module-scoped symbol (i.e. utterly Tk-internal) to Tk's internal stubs table. No big deal if the symbol is needed. > I'm not sure why commenting out the "module scope" bits worked; I'm sure > that is there for a reason, but it's not clear to me. The module scope stuff is about trying to clean up the Tcl/Tk core so that symbols are exactly as widely available as they need to be. This really stems from the fact that its introducing a concept that traditional Unix linkers didn't support; symbol visibility wider than the file level but less than the application level. Donal. |
|
From: Daniel A. S. <st...@ic...> - 2005-09-30 04:54:37
|
Donal, On Thursday, Sep 29, 2005, at 18:30 Australia/Sydney, Donal K. Fellows wrote: > Kevin Walzer wrote: >> Earlier, the build was dying after complaining that some defintions in >> tkMacOSXInt.h had errors. Looking at the code in question, I noticed >> that the lines began with the phrase "Module Scope," like this: >> ~ MODULE_SCOPE int TkMacOSXUseAntialiasedText(Tcl_Interp *interp, int >> enable); >> Commenting out those lines and replacing them without the phrase >> "module >> scope" allowed the build to proceed, and I built Tile and Tktreectrl >> successfully in the standard fashion (not as universal binaries). > > OK, that might indicate that TkMacOSXUseAntialiasedText may need to be > promoted from a module-scoped symbol (i.e. utterly Tk-internal) to Tk's > internal stubs table. No big deal if the symbol is needed. I think the problem was more that I had introduced MODULE_SCOPE to tkaqua headers without adding the conditional definition of MODULE_SCOPE to tkInt.h from tclInt.h (will fix that when I commit various other small changes) As MODULE_SCOPE is defined by tk configure on Mac OS X, this did not show up when building tk itself, only when using internal tkaqua headers from an extension where MODULE_SCOPE is not AC_DEFINEd... >> I'm not sure why commenting out the "module scope" bits worked; I'm >> sure >> that is there for a reason, but it's not clear to me. > > The module scope stuff is about trying to clean up the Tcl/Tk core so > that symbols are exactly as widely available as they need to be. This > really stems from the fact that its introducing a concept that > traditional Unix linkers didn't support; symbol visibility wider than > the file level but less than the application level. FWIW, it appears the NEXT MachO linker had supported this with __private_extern__ for a long time, and the Mac OS X linker continues to do so, hence our #define MODULE_SCOPE __private_extern__ The only issue is that prior to Mac OS X 10.4, MODULE_SCOPE has to be present both at function declaration and function definition for the symbol to be unexported, I've started doing that in macosx specific tcl/tk sources, but not in the generic sources Cheers, Daniel -- ** Daniel A. Steffen ** "And now for something completely ** Dept. of Mathematics ** different" Monty Python ** Macquarie University ** <mailto:st...@ma...> ** NSW 2109 Australia ** <http://www.maths.mq.edu.au/~steffen/> |
