Jesper . Naur <[EMAIL PROTECTED]> writes:
>Hello everybody.
>
>I'm in the process of upgrading "Perl/Tk on VMS" to work with Tk800.018, and things
>are going quite well (I have the "Hello World" program running, as well as 'almost'
>all tests, albeit after some hand-tickling during Tk build!). However, there are some
>'interesting' problems:
>
>1) Compile-time name duplication in [.EVENT]EVENT.XS, due to VMS case insensivity.
>
>[.EVENT]EVENT.XS contains
>
>[snip]
>#define Const_READABLE() TCL_READABLE
>#define Const_WRITABLE() TCL_WRITABLE
>#define Const_EXCEPTION() TCL_EXCEPTION
>[snip]
>MODULE = Tk::Event PACKAGE = Tk::Event::IO PREFIX = Const_
>
>PROTOTYPES: ENABLE
>
>int
>Const_READABLE()
>
>int
>Const_WRITABLE()
>
>int
>Const_EXCEPTION()
>[snip]
>MODULE = Tk::Event PACKAGE = Tk::Event::IO PREFIX = PerlIO_
>[snip]
>int
>PerlIO_readable(filePtr)
>PerlIOHandler * filePtr
>
>int
>PerlIO_exception(filePtr)
>PerlIOHandler * filePtr
>
>int
>PerlIO_writable(filePtr)
>PerlIOHandler * filePtr
>
>This is translated by xsubpp into (with major snippage):
>
>[snip]
>XS(XS_Tk__Event__IO_READABLE)
>[snip]
>XS(XS_Tk__Event__IO_WRITABLE)
>[snip]
>XS(XS_Tk__Event__IO_EXCEPTION)
>[snip]
>
>XS(XS_Tk__Event__IO_readable)
>[snip]
>XS(XS_Tk__Event__IO_exception)
>[snip]
>XS(XS_Tk__Event__IO_writable)
>[snip]
>
>Problem here is of course, that the names only differ in character case, and will
>pairwise look identical to the C-compiler, at least the way, we normally work under
>VMS (all names visible to the linker are converted to upper-case).
>
>Solution # 1: Change the upper-case names in EVENT.XS to ...RDABLE, ...WRTABLE and
>...EXCPTION. This will get rid of the compile-time name duplication, but will of
>course also require changes to
>[.EVENT.EVENT]IO.PM in order to use the new names. Since [.EVENT.EVENT]IO.PM exports
>READABLE and WRITABLE, IO.PM must be extended with new subroutines READABLE and
>WRITABLE, which simply return RDABLE and WRTABLE respectively. This is of course only
>necessary, if the exported names READABLE and WRITABLE are actually intended to be
>used by anyone (I have been unable to find any uses, and the POD descriptions are
>vague in this area). I personally believe, that this solution can be brought to work.
>
>"Solution" # 2: Add "/NAMES=AS_IS" to the C-compiler options used to compile the
>C-code. This will most likely have the eventual consequence, that all of perl must be
>recompiled with this option, and it is also likely, that it will cause a number of
>other unpleasant problems (an example: All names in DECW$XLIBSHR are upper-case, so a
>simple thing like XOpenDisplay will end up being undefined...).
>I wonder, what you all would have to say about that ...
Another Solution might be to make the XS functions "static".
The issue with that being that it can cause problems with B::* backends.
Other schemes could be invented too.
>
>2) Many undefined's when linking [.EVENT]EVENT.EXE
>
>I get 119 undefineds during link - the first 10 are listed here:
>
>LANGCLIENTMESSAGE
>LANGCMPARG
>LANGCMPOPT
>LANGCOPYARG
>LANGDEADWINDOW
>LANGDOCALLBACK
>LANGEVAL
>LANGEVENTCALLBACK
>LANGFINDVAR
>LANGFONTARG
>These names, including the remaining 109, are all defined in the object
>library [-.blib.arch.auto.Tk]TK.OLB, so by modifying [.EVENT]EVENT.OPT to include
>[-.blib.arch.auto.Tk]TK.OLB, it becomes possible to link EVENT.EXE by hand.
That is odd - it would seem that your C compiler is creating references
to things which are not used. i.e. just an
extern foo();
Is enough to force need for foo.
That is not normal C behaviour.
>
>The problem is however, that during a regular build, TK.OLB is built after the
>linking of EVENT.EXE. So two things need to be solved: TK.OLB must be built before
>EVENT.EXE is linked, and the reference to TK.OLB must be added to EVENT.OPT, this
>should all somehow be a part of the building procedure. Or maybe this should be
>solved in an entirely different way.
>
>Any ideas would be greatly appreciated.
>
>3) Several link-time duplicate global names when linking EVENT.EXE.
>
>When linking EVENT.EXE by hand as described above, the following names have duplicate
>definitions:
>
>TCL_ALLOC
>TCL_ASYNCINVOKE
>TCL_ASYNCREADY
>TCL_FREE
>TCL_PANIC
>LANGEXIT
>LANGDEBUG
>LANG_OSHANDLE
That list has been fixed in Tk800.019-to-be - for other reasons.
--
Nick Ing-Simmons
