jesper naur wrote:
> 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=20
> [.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.
This would be preferable if Nick is amenable to it.
> "Solution" # 2: Add "/NAMES=3DAS_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 ...
This reminds me: Dan, didn't you want to put symbol case sensitivity
into vmsperl? What happened there?
> 2) Many undefined's when linking [.EVENT]EVENT.EXE
>
> I get 119 undefineds during link - the first 10 are listed here:
>
> LANGCLIENTMESSAGE=20
> LANGCMPARG=20
> LANGCMPOPT=20
> LANGCOPYARG=20
> LANGDEADWINDOW=20
> LANGDOCALLBACK=20
> LANGEVAL=20
> LANGEVENTCALLBACK=20
> LANGFINDVAR=20
> LANGFONTARG=20
>
> 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.
>
> 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.
How about a VMS specific post amble to the relevant Makefile.PL?
> 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
>
> These names are all defined by various modules from TK.OLB, however they =
> also exist in []TKGLUE.C. To get rid of the error messages, I can easily =
> delete them from their original modules (perhaps conditioned as =
> VMS-specific) but is this the right thing to do?
I am not sure.
Peter Prymmer
