Re: Building libxml2 on OpenVMS/VAX - VMS

This is a discussion on Re: Building libxml2 on OpenVMS/VAX - VMS ; From: "Andreas W. Wylach" > To my problem: Since 2 days I try to build the libxml2 library on my > Vax (a VaxStation 4000/96 with > OpenVMS 7.3 with Compaq C V6.4-005). Sounds dangerous. > CC/NAMES=(SHORTENED)/FLOAT=D_FLOAT/object=DKA300: > [AW.LIBXML2-2_6_30.DEBUG]HTMLTR > ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Re: Building libxml2 on OpenVMS/VAX

  1. Re: Building libxml2 on OpenVMS/VAX

    From: "Andreas W. Wylach"

    > To my problem: Since 2 days I try to build the libxml2 library on my
    > Vax (a VaxStation 4000/96 with
    > OpenVMS 7.3 with Compaq C V6.4-005).


    Sounds dangerous.

    > CC/NAMES=(SHORTENED)/FLOAT=D_FLOAT/object=DKA300:
    > [AW.LIBXML2-2_6_30.DEBUG]HTMLTR
    > EE.OBJ; HTMLTREE.C
    > typedef long double trio_long_double_t;
    > ........^
    > %CC-I-LONGDOUBLENYI, In this declaration, type long double has the
    > same
    > representation as type double on this platform.
    > At line number 156 in DKA300:
    > [AW.LIBXML2-2_6_30]TRIODEF.H;1.


    So? Whether that's a real problem depends on now many bits it really
    uses for trio_long_double_t variables. Without looking at the code, I
    have no idea.

    > The compilation procedure gets thru and results in the libxml.olb
    > library. Another problem is, that I get one undefined symbol
    > (fp_class).


    When you do what?

    > Overall, these problems seem to be resolvable but I have
    > the string feeling, that
    > I won't be able to build that library on OpenVMS /VAX. As far as I
    > know it can be build on an Alpha. With the
    > libxml2 distribution there's also an vms build procedure (which I
    > use).


    > cc_opts = "/NAMES=(SHORTENED)/FLOAT=IEEE/IEEE_MODE=DENORM_RESULTS"


    IEEE floating point is not available on VAX. Again, without looking
    at the code, it would be hard to say how important that would be.

    > [...] Tried to install
    > the c++ compiler but get an vmsinstal
    > installtion error that reports some undefined logicals. So for now I
    > leave the c++ installation for later.
    >
    > Any hints to get me to an result are greatly appreciated. If I forgot
    > to give any important info, please let me know.


    Which one is "the c++ compiler"? As usual, actual commands and
    actual error messages would be more informative than vague descriptions.

    ------------------------------------------------------------------------

    Steven M. Schweda sms@antinode-org
    382 South Warwick Street (+1) 651-699-9818
    Saint Paul MN 55105-2547

  2. Re: Building libxml2 on OpenVMS/VAX

    On 7 Jan., 11:58, s...@antinode.org (Steven M. Schweda) wrote:
    > From: "Andreas W. Wylach"
    >
    > > To my problem: Since 2 days I try to build the libxml2 library on my
    > > Vax (a VaxStation 4000/96 with
    > > OpenVMS 7.3 with Compaq C V6.4-005).

    >
    > Sounds dangerous.
    >
    > > CC/NAMES=(SHORTENED)/FLOAT=D_FLOAT/object=DKA300:
    > > [AW.LIBXML2-2_6_30.DEBUG]HTMLTR
    > > EE.OBJ; HTMLTREE.C
    > > typedef long double trio_long_double_t;
    > > ........^
    > > %CC-I-LONGDOUBLENYI, In this declaration, type long double has the
    > > same
    > > representation as type double on this platform.
    > > At line number 156 in DKA300:
    > > [AW.LIBXML2-2_6_30]TRIODEF.H;1.

    >
    > So? Whether that's a real problem depends on now many bits it really
    > uses for trio_long_double_t variables. Without looking at the code, I
    > have no idea.


    Well, I can't tell. I've never dealed with the fp/fp_class stuff in my
    life so I just changed that
    long double to double (like it stated in the compiler message). I know
    it sounds naive, but
    I have no other clue yet.

    >
    > > The compilation procedure gets thru and results in the libxml.olb
    > > library. Another problem is, that I get one undefined symbol
    > > (fp_class).

    >
    > When you do what?


    This linker moans about the undefined fp_class symbol, when it comes
    to the point
    linking some cleint programs (like nanoftp, nanohttp, etc) using the
    libxml.olb library.

    >
    > > Overall, these problems seem to be resolvable but I have
    > > the string feeling, that
    > > I won't be able to build that library on OpenVMS /VAX. As far as I
    > > know it can be build on an Alpha. With the
    > > libxml2 distribution there's also an vms build procedure (which I
    > > use).
    > > cc_opts = "/NAMES=(SHORTENED)/FLOAT=IEEE/IEEE_MODE=DENORM_RESULTS"

    >
    > IEEE floating point is not available on VAX. Again, without looking
    > at the code, it would be hard to say how important that would be.


    I know, I already saw that in the cc/decc help. I was just wondering
    if there's an equivalent
    compiler directive / command for the VAX.

    >
    > > [...] Tried to install
    > > the c++ compiler but get an vmsinstal
    > > installtion error that reports some undefined logicals. So for now I
    > > leave the c++ installation for later.

    >
    > > Any hints to get me to an result are greatly appreciated. If I forgot
    > > to give any important info, please let me know.

    >
    > Which one is "the c++ compiler"? As usual, actual commands and
    > actual error messages would be more informative than vague descriptions.


    Its a saveset (cxx056.a) containing the VAX C++ V5.6 compiler from the
    HP C/C++ page I downloaded. Somebody
    solved the problem by hacking the kitinstal.com file and several other
    adjustments. See
    http://unix.derkeiler.com/Newsgroups...3-04/1937.html

    If I had more information on the problem I would have mentioned it in
    here. All I get
    are messages about 3 undefined logicals. That's it.

    The fact that I need to get into VMS a lilttle more again (I work on
    unix/linux) I skipped installing
    the c++ compiler cause I don't know what exactly to change in that dcl
    file. Need to do a little
    more debugging on that (set verify on, etc). When I've done that I
    might return with that problem
    to the group to give detailed info's. I will try to solve that c++
    compiler problem, when I have
    more time to dip into that subject.

    For the libxml2 I do not need the c++ compiler.

    My general question was, if anybody sucessfully built that libxml2
    library on OpenVMS/VAX. If
    not, I think it's lost time to continue that and I just skip the xls/
    xml project on the VAX. If yes,
    it would be nice if I could get a copy of the distribution or at least
    the changes / diff that was made.

    Btw, the libraries I tried to build is libxml2-2.6.30 (that is the
    latest) and also the 5 year old
    library libxml2-2.6.0. (both are ready for OpenVMS and contain the
    build scripts for VMS).
    The port was done by John A Fotheringham in 2001, 7 years ago.

    Andreas W. Wylach

    >
    > ------------------------------------------------------------------------
    >
    > Steven M. Schweda sms@antinode-org
    > 382 South Warwick Street (+1) 651-699-9818
    > Saint Paul MN 55105-2547



  3. Re: Building libxml2 on OpenVMS/VAX

    In article , "Andreas W. Wylach" writes:
    >
    >
    >On 7 Jan., 11:58, s...@antinode.org (Steven M. Schweda) wrote:
    >> From: "Andreas W. Wylach"
    >>
    >> > To my problem: Since 2 days I try to build the libxml2 library on my
    >> > Vax (a VaxStation 4000/96 with
    >> > OpenVMS 7.3 with Compaq C V6.4-005).

    >>
    >> Sounds dangerous.
    >>
    >> > CC/NAMES=(SHORTENED)/FLOAT=D_FLOAT/object=DKA300:
    >> > [AW.LIBXML2-2_6_30.DEBUG]HTMLTR
    >> > EE.OBJ; HTMLTREE.C
    >> > typedef long double trio_long_double_t;
    >> > ........^
    >> > %CC-I-LONGDOUBLENYI, In this declaration, type long double has the
    >> > same
    >> > representation as type double on this platform.
    >> > At line number 156 in DKA300:
    >> > [AW.LIBXML2-2_6_30]TRIODEF.H;1.

    >>
    >> So? Whether that's a real problem depends on now many bits it really
    >> uses for trio_long_double_t variables. Without looking at the code, I
    >> have no idea.

    >
    >Well, I can't tell. I've never dealed with the fp/fp_class stuff in my
    >life so I just changed that
    >long double to double (like it stated in the compiler message). I know
    >it sounds naive, but
    >I have no other clue yet.


    $ HELP CC LANGUAGE DATA_TYPES...

    float 32-bit (single-precision) floating-point number
    double 64-bit (double-precision) floating-point number
    long float Interchangeable with double, but usage is
    obsolete

    Perhaps, it's just an old coding hangover from when the datum was changed
    from long float (which this above says is obsolete usage) to double. I'd
    remove the 'long' or, if you want, conditionalize that for the VMS build.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    "Well my son, life is like a beanstalk, isn't it?"

    http://tmesis.com/drat.html

  4. Re: Building libxml2 on OpenVMS/VAX

    On 7 Jan., 14:02, VAXman- @SendSpamHere.ORG wrote:
    > In article , "Andreas W. Wylach" writes:
    >
    >
    >
    >
    >
    > >On 7 Jan., 11:58, s...@antinode.org (Steven M. Schweda) wrote:
    > >> From: "Andreas W. Wylach"

    >
    > >> > To my problem: Since 2 days I try to build the libxml2 library on my
    > >> > Vax (a VaxStation 4000/96 with
    > >> > OpenVMS 7.3 with Compaq C V6.4-005).

    >
    > >> Sounds dangerous.

    >
    > >> > CC/NAMES=(SHORTENED)/FLOAT=D_FLOAT/object=DKA300:
    > >> > [AW.LIBXML2-2_6_30.DEBUG]HTMLTR
    > >> > EE.OBJ; HTMLTREE.C
    > >> > typedef long double trio_long_double_t;
    > >> > ........^
    > >> > %CC-I-LONGDOUBLENYI, In this declaration, type long double has the
    > >> > same
    > >> > representation as type double on this platform.
    > >> > At line number 156 in DKA300:
    > >> > [AW.LIBXML2-2_6_30]TRIODEF.H;1.

    >
    > >> So? Whether that's a real problem depends on now many bits it really
    > >> uses for trio_long_double_t variables. Without looking at the code, I
    > >> have no idea.

    >
    > >Well, I can't tell. I've never dealed with the fp/fp_class stuff in my
    > >life so I just changed that
    > >long double to double (like it stated in the compiler message). I know
    > >it sounds naive, but
    > >I have no other clue yet.

    >
    > $ HELP CC LANGUAGE DATA_TYPES...
    >
    > float 32-bit (single-precision) floating-point number
    > double 64-bit (double-precision) floating-point number
    > long float Interchangeable with double, but usage is
    > obsolete
    >
    > Perhaps, it's just an old coding hangover from when the datum was changed
    > from long float (which this above says is obsolete usage) to double. I'd
    > remove the 'long' or, if you want, conditionalize that for the VMS build.
    >
    > --
    > VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
    >
    > "Well my son, life is like a beanstalk, isn't it?"
    >
    > http://tmesis.com/drat.html


    yeah, that is what I did. Well, just try to compile an way older
    version of libxml (libxml2-2_4_27). Maybe I get
    one step further with that .... In those situations I wished I had an
    Alpha Server with newer compilers/Libs or something.
    But I still love my Vax'es .-))

    Andreas W Wylach

  5. Re: Building libxml2 on OpenVMS/VAX

    In article , "Andreas W. Wylach" writes:
    >
    > This linker moans about the undefined fp_class symbol, when it comes
    > to the point
    > linking some cleint programs (like nanoftp, nanohttp, etc) using the
    > libxml.olb library.


    You need to find out what fp_class is, how it is used, and where
    you can get it.

    >
    > I know, I already saw that in the cc/decc help. I was just wondering
    > if there's an equivalent
    > compiler directive / command for the VAX.


    Why would the compiler have a directive to use something that doesn't
    exist?


  6. Re: Building libxml2 on OpenVMS/VAX

    In article , "Andreas W. Wylach" writes:
    > On 7 Jan., 14:02, VAXman- @SendSpamHere.ORG wrote:
    >> In article , "Andreas W. Wylach" writes:
    >> >On 7 Jan., 11:58, s...@antinode.org (Steven M. Schweda) wrote:
    >> >> From: "Andreas W. Wylach"

    >>
    >> >> > To my problem: Since 2 days I try to build the libxml2 library on my
    >> >> > Vax (a VaxStation 4000/96 with
    >> >> > OpenVMS 7.3 with Compaq C V6.4-005).

    >>
    >> >> Sounds dangerous.

    >>
    >> >> > CC/NAMES=(SHORTENED)/FLOAT=D_FLOAT/object=DKA300:
    >> >> > [AW.LIBXML2-2_6_30.DEBUG]HTMLTR
    >> >> > EE.OBJ; HTMLTREE.C
    >> >> > typedef long double trio_long_double_t;
    >> >> > ........^
    >> >> > %CC-I-LONGDOUBLENYI, In this declaration, type long double has the
    >> >> > same
    >> >> > representation as type double on this platform.
    >> >> > At line number 156 in DKA300:
    >> >> > [AW.LIBXML2-2_6_30]TRIODEF.H;1.

    >>
    >> >> So? Whether that's a real problem depends on now many bits it really
    >> >> uses for trio_long_double_t variables. Without looking at the code, I
    >> >> have no idea.

    >>
    >> >Well, I can't tell. I've never dealed with the fp/fp_class stuff in my
    >> >life so I just changed that
    >> >long double to double (like it stated in the compiler message). I know
    >> >it sounds naive, but
    >> >I have no other clue yet.

    >>
    >> $ HELP CC LANGUAGE DATA_TYPES...
    >>
    >> float 32-bit (single-precision) floating-point number
    >> double 64-bit (double-precision) floating-point number
    >> long float Interchangeable with double, but usage is
    >> obsolete
    >>
    >> Perhaps, it's just an old coding hangover from when the datum was changed
    >> from long float (which this above says is obsolete usage) to double. I'd
    >> remove the 'long' or, if you want, conditionalize that for the VMS build.
    >>
    >> --
    >> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
    >>
    >> "Well my son, life is like a beanstalk, isn't it?"
    >>
    >> http://tmesis.com/drat.html

    >
    > yeah, that is what I did. Well, just try to compile an way older
    > version of libxml (libxml2-2_4_27). Maybe I get
    > one step further with that .... In those situations I wished I had an
    > Alpha Server with newer compilers/Libs or something.
    > But I still love my Vax'es .-))


    Just recently I finished getting libxml2-2_4_27 to build on VAX with
    both DEC C and VAX C for use with VMS Mosaic. The main issue I ran
    into was the need for IEEE floating point; several functions depend
    on IEEE behaviors which are not available on VAX. Fortunately, I do
    not think Mosiac's usage of libxml2 will be affected by the lack of
    these behaviors. I can zip up what I have and put it out for FTP.

    If your application depends on the unavailable IEEE behaviors, then
    you could be in for major problems. I'm not sure how much (or when)
    libxml2 actually makes use of these behaviors.

    As far as D_FLOAT vs. G_FLOAT, I used G_FLOAT because it is the closest
    match for libxml2's use of IEEE floating point.


    George Cook
    WVNET

  7. Re: Building libxml2 on OpenVMS/VAX

    George Cook wrote:
    > Just recently I finished getting libxml2-2_4_27 to build on VAX with
    > both DEC C and VAX C for use with VMS Mosaic. The main issue I ran
    > into was the need for IEEE floating point; several functions depend
    > on IEEE behaviors which are not available on VAX. Fortunately, I do
    > not think Mosiac's usage of libxml2 will be affected by the lack of
    > these behaviors. I can zip up what I have and put it out for FTP.
    >
    > If your application depends on the unavailable IEEE behaviors, then
    > you could be in for major problems. I'm not sure how much (or when)
    > libxml2 actually makes use of these behaviors.
    >
    > As far as D_FLOAT vs. G_FLOAT, I used G_FLOAT because it is the closest
    > match for libxml2's use of IEEE floating point.


    I know I could look in the code myself, but WTF does a XML parser
    need floating point for ?

    xsd:double in schema's ?

    Arne

  8. Re: Building libxml2 on OpenVMS/VAX

    In article <2UxR5LiUDSYl@wvnvms>, cook@wvnvms.wvnet.edu (George Cook)
    wrote:

    > In article
    > , "Andreas
    > W. Wylach" writes:
    > > On 7 Jan., 14:02, VAXman- @SendSpamHere.ORG wrote:
    > >> In article
    > >> ,
    > >> "Andreas W. Wylach" writes:
    > >> >On 7 Jan., 11:58, s...@antinode.org (Steven M. Schweda) wrote:
    > >> >> From: "Andreas W. Wylach"
    > >>
    > >> >> > To my problem: Since 2 days I try to build the libxml2 library on my
    > >> >> > Vax (a VaxStation 4000/96 with
    > >> >> > OpenVMS 7.3 with Compaq C V6.4-005).


    libxml2 is an outstanding hunk of software. If you don't need a
    validating parser, though, also consider expat.


    > >> >> > CC/NAMES=(SHORTENED)/FLOAT=D_FLOAT/object=DKA300:
    > >> >> > [AW.LIBXML2-2_6_30.DEBUG]HTMLTR
    > >> >> > EE.OBJ; HTMLTREE.C
    > >> >> > typedef long double trio_long_double_t;
    > >> >> > ........^
    > >> >> > %CC-I-LONGDOUBLENYI, In this declaration, type long double has the
    > >> >> > same
    > >> >> > representation as type double on this platform.
    > >> >> > At line number 156 in DKA300:
    > >> >> > [AW.LIBXML2-2_6_30]TRIODEF.H;1.
    > >>
    > >> >> So? Whether that's a real problem depends on now many bits it
    > >> >> really
    > >> >> uses for trio_long_double_t variables. Without looking at the code, I
    > >> >> have no idea.
    > >>
    > >> >Well, I can't tell. I've never dealed with the fp/fp_class stuff in my
    > >> >life so I just changed that
    > >> >long double to double (like it stated in the compiler message). I know
    > >> >it sounds naive, but
    > >> >I have no other clue yet.
    > >>
    > >> $ HELP CC LANGUAGE DATA_TYPES...
    > >>
    > >> float 32-bit (single-precision) floating-point number
    > >> double 64-bit (double-precision) floating-point number
    > >> long float Interchangeable with double, but usage is
    > >> obsolete


    You left out:

    long double 128-bit (double-precision) floating-point
    number

    which appears when I use the same help command you did with HP C
    V7.3-009 on OpenVMS Alpha V8.3 installed. For whatever reason, I don't
    think VAX C or DEC C on OpenVMS VAX ever implemented long double as an
    H_FLOAT, which would have been the natural thing to do (REAL*16 for you
    FORTRAN folks). But on 64-bit OpenVMS platforms with IEEE floating
    point enabled, long double does produce an X_FLOAT, which is twice as
    big as an ordinary double.

    > >>
    > >> Perhaps, it's just an old coding hangover from when the datum was changed
    > >> from long float (which this above says is obsolete usage) to double. I'd
    > >> remove the 'long' or, if you want, conditionalize that for the VMS build.


    If it's conditionalized you definitely want to conditionalize it for
    VAX, not VMS, seeing as long double does give a double that twice as
    long as an ordinary double on 64-bit OpenVMS platforms.

    > Just recently I finished getting libxml2-2_4_27 to build on VAX with
    > both DEC C and VAX C for use with VMS Mosaic. The main issue I ran
    > into was the need for IEEE floating point; several functions depend
    > on IEEE behaviors which are not available on VAX. Fortunately, I do
    > not think Mosiac's usage of libxml2 will be affected by the lack of
    > these behaviors. I can zip up what I have and put it out for FTP.
    >
    > If your application depends on the unavailable IEEE behaviors, then
    > you could be in for major problems. I'm not sure how much (or when)
    > libxml2 actually makes use of these behaviors.
    >
    > As far as D_FLOAT vs. G_FLOAT, I used G_FLOAT because it is the closest
    > match for libxml2's use of IEEE floating point.


    Agreed. You'd almost certainly be better off with G_FLOAT since its
    range is much closer to IEEE than D_FLOAT's is. However, you should
    build with the same option that was used to build whatever you'll be
    linking with, such as Perl or WASD. And there is nothing corresponding
    to IEEE exception handling, NaNs, etc. Whether that causes trouble
    depends entirely on what XML you end up parsing. Validating against
    data-oriented schemas that do range checking or enforce other numeric
    rules will probably cause your parser to blow up spectacularly. But if
    you never see such schemas or attempt to do validation you'll probably
    be fine.

    On the fp_class problem:

    $ help crtl fp_class

    CRTL

    fp_class

    Determines the class of IEEE floating-point values.

    This function is OpenVMS Alpha and I64 only.


    In other words, its absence is important, but you can't get it on VAX,
    or at least not unless you want to roll your own IEEE floating point in
    software, including standard run-time library support for same.

    --
    Posted via a free Usenet account from http://www.teranews.com


  9. Re: Building libxml2 on OpenVMS/VAX

    In article <4782e516$0$90274$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes:
    > George Cook wrote:
    >> Just recently I finished getting libxml2-2_4_27 to build on VAX with
    >> both DEC C and VAX C for use with VMS Mosaic. The main issue I ran
    >> into was the need for IEEE floating point; several functions depend
    >> on IEEE behaviors which are not available on VAX. Fortunately, I do
    >> not think Mosiac's usage of libxml2 will be affected by the lack of
    >> these behaviors. I can zip up what I have and put it out for FTP.
    >>
    >> If your application depends on the unavailable IEEE behaviors, then
    >> you could be in for major problems. I'm not sure how much (or when)
    >> libxml2 actually makes use of these behaviors.
    >>
    >> As far as D_FLOAT vs. G_FLOAT, I used G_FLOAT because it is the closest
    >> match for libxml2's use of IEEE floating point.

    >
    > I know I could look in the code myself, but WTF does a XML parser
    > need floating point for ?
    >
    > xsd:double in schema's ?


    I am far from being an expert on XML or libxml2, but some XML does
    use floating point. An SVG image is an XML file which can contain
    a lot of floating point values. Mosaic will use libxml2 for SVG
    images and style sheets, and I did just enough investigation to be
    reasonably sure that using G_FLOAT instead of IEEE will not cause
    significant problems. That, however, may not be the case for other
    applications.


    George Cook
    WVNET

  10. Re: Building libxml2 on OpenVMS/VAX

    On 8 Jan., 04:39, "Craig A. Berry"
    wrote:
    > In article <2UxR5LiUDSYl@wvnvms>, c...@wvnvms.wvnet.edu (George Cook)
    > wrote:
    >
    > > In article
    > > , "Andreas
    > > W. Wylach" writes:
    > > > On 7 Jan., 14:02, VAXman- @SendSpamHere.ORG wrote:
    > > >> In article
    > > >> ,
    > > >> "Andreas W. Wylach" writes:
    > > >> >On 7 Jan., 11:58, s...@antinode.org (Steven M. Schweda) wrote:
    > > >> >> From: "Andreas W. Wylach"

    >
    > > >> >> > To my problem: Since 2 days I try to build the libxml2 library on my
    > > >> >> > Vax (a VaxStation 4000/96 with
    > > >> >> > OpenVMS 7.3 with Compaq C V6.4-005).

    >
    > libxml2 is an outstanding hunk of software. If you don't need a
    > validating parser, though, also consider expat.
    >
    >
    >
    > > >> >> > CC/NAMES=(SHORTENED)/FLOAT=D_FLOAT/object=DKA300:
    > > >> >> > [AW.LIBXML2-2_6_30.DEBUG]HTMLTR
    > > >> >> > EE.OBJ; HTMLTREE.C
    > > >> >> > typedef long double trio_long_double_t;
    > > >> >> > ........^
    > > >> >> > %CC-I-LONGDOUBLENYI, In this declaration, type long double has the
    > > >> >> > same
    > > >> >> > representation as type double on this platform.
    > > >> >> > At line number 156 in DKA300:
    > > >> >> > [AW.LIBXML2-2_6_30]TRIODEF.H;1.

    >
    > > >> >> So? Whether that's a real problem depends on now many bits it
    > > >> >> really
    > > >> >> uses for trio_long_double_t variables. Without looking at the code, I
    > > >> >> have no idea.

    >
    > > >> >Well, I can't tell. I've never dealed with the fp/fp_class stuff in my
    > > >> >life so I just changed that
    > > >> >long double to double (like it stated in the compiler message). I know
    > > >> >it sounds naive, but
    > > >> >I have no other clue yet.

    >
    > > >> $ HELP CC LANGUAGE DATA_TYPES...

    >
    > > >> float 32-bit (single-precision) floating-point number
    > > >> double 64-bit (double-precision) floating-point number
    > > >> long float Interchangeable with double, but usage is
    > > >> obsolete

    >
    > You left out:
    >
    > long double 128-bit (double-precision) floating-point
    > number
    >
    > which appears when I use the same help command you did with HP C
    > V7.3-009 on OpenVMS Alpha V8.3 installed. For whatever reason, I don't
    > think VAX C or DEC C on OpenVMS VAX ever implemented long double as an
    > H_FLOAT, which would have been the natural thing to do (REAL*16 for you
    > FORTRAN folks). But on 64-bit OpenVMS platforms with IEEE floating
    > point enabled, long double does produce an X_FLOAT, which is twice as
    > big as an ordinary double.
    >
    >
    >
    > > >> Perhaps, it's just an old coding hangover from when the datum was changed
    > > >> from long float (which this above says is obsolete usage) to double. I'd
    > > >> remove the 'long' or, if you want, conditionalize that for the VMS build.

    >
    > If it's conditionalized you definitely want to conditionalize it for
    > VAX, not VMS, seeing as long double does give a double that twice as
    > long as an ordinary double on 64-bit OpenVMS platforms.
    >
    > > Just recently I finished getting libxml2-2_4_27 to build on VAX with
    > > both DEC C and VAX C for use with VMS Mosaic. The main issue I ran
    > > into was the need for IEEE floating point; several functions depend
    > > on IEEE behaviors which are not available on VAX. Fortunately, I do
    > > not think Mosiac's usage of libxml2 will be affected by the lack of
    > > these behaviors. I can zip up what I have and put it out for FTP.

    >
    > > If your application depends on the unavailable IEEE behaviors, then
    > > you could be in for major problems. I'm not sure how much (or when)
    > > libxml2 actually makes use of these behaviors.

    >
    > > As far as D_FLOAT vs. G_FLOAT, I used G_FLOAT because it is the closest
    > > match for libxml2's use of IEEE floating point.

    >
    > Agreed. You'd almost certainly be better off with G_FLOAT since its
    > range is much closer to IEEE than D_FLOAT's is. However, you should
    > build with the same option that was used to build whatever you'll be
    > linking with, such as Perl or WASD. And there is nothing corresponding
    > to IEEE exception handling, NaNs, etc. Whether that causes trouble
    > depends entirely on what XML you end up parsing. Validating against
    > data-oriented schemas that do range checking or enforce other numeric
    > rules will probably cause your parser to blow up spectacularly. But if
    > you never see such schemas or attempt to do validation you'll probably
    > be fine.
    >
    > On the fp_class problem:
    >
    > $ help crtl fp_class
    >
    > CRTL
    >
    > fp_class
    >
    > Determines the class of IEEE floating-point values.
    >
    > This function is OpenVMS Alpha and I64 only.
    >
    > In other words, its absence is important, but you can't get it on VAX,
    > or at least not unless you want to roll your own IEEE floating point in
    > software, including standard run-time library support for same.
    >
    > --
    > Posted via a free Usenet account fromhttp://www.teranews.com


    Well, I even tried another port Hoff pointed me to, the libxml2-2-6-27
    version and I aint getting
    any step further. I get the same results like I had with the 30
    subversion and even trying
    an older version , like 2.4.x is not working out. It's all about the
    fp_class and floating point
    construcs/constants in the trio files. I have no clue, how they got
    build on the vax, there's
    even no diffs for VAX. The code-intern fallback method is also not
    working and leads
    to an access violation. When it comes to the link process of the
    trionan test files
    my compiler bails out with an bugcheck ....

    My main reason getting the libxml2 running on OpenVMS/VAX is to use
    the
    libxml perl modules for my dynamic XML/XSL homepage parser, a cms-
    based perl/xml/xsl
    construct I developed on linux. On linux tho it uses the Sablotron
    Parser. I want to open
    my OpenVMS hobby homepage with my VAX and therefore wanted to
    implement that
    dynamic perl homepage parser with WASD 9.2 server using perl rte
    (which already runs
    nicely).

    Unless nobody states me any solution for the libxml2, I will skip that
    library, try to
    get solved my c++ installation issues on my VAX and try to compile the
    Sablotron
    Parser to OpenVMS/VAX. That would be even a better solution, I would
    not need
    to change the perl cms code, that is already running.

    I have the expat running on my VAX, there was no problems at all, but
    it's not enough
    for my application. I need a parser that incorporates xml in my xsl
    stylesheets and
    expat wont do that for me the way I need it. I want to try not
    to use lot's of perl modules and want to keep the perl Application as
    small as possible
    for performance reasons and try to keep the html generation under 5
    seconds (on the VAX).
    Even tho for calling content items I need the xpath functionality.
    Without that the whole
    thing is not working.

    An example for the my parser is my street-lights info/collection
    homepage (http://www.street-lights.info), just if you guys want to
    know what I
    am talking about.-))

    Andreas W. Wylach

  11. Re: Building libxml2 on OpenVMS/VAX

    In article <3958418c-3e2a-464a-b22a-449ef5867b7c@r60g2000hsc.googlegroups.com>, "Andreas W. Wylach" writes:
    > On 8 Jan., 04:39, "Craig A. Berry"
    > wrote:
    >> In article <2UxR5LiUDSYl@wvnvms>, c...@wvnvms.wvnet.edu (George Cook)
    >> wrote:
    >>
    >> > In article
    >> > , "Andreas
    >> > W. Wylach" writes:
    >> > > On 7 Jan., 14:02, VAXman- @SendSpamHere.ORG wrote:
    >> > >> In article
    >> > >> ,
    >> > >> "Andreas W. Wylach" writes:
    >> > >> >On 7 Jan., 11:58, s...@antinode.org (Steven M. Schweda) wrote:
    >> > >> >> From: "Andreas W. Wylach"

    >>
    >> > >> >> > To my problem: Since 2 days I try to build the libxml2 library on my
    >> > >> >> > Vax (a VaxStation 4000/96 with
    >> > >> >> > OpenVMS 7.3 with Compaq C V6.4-005).

    >>
    >> libxml2 is an outstanding hunk of software. If you don't need a
    >> validating parser, though, also consider expat.
    >>
    >>
    >>
    >> > >> >> > CC/NAMES=(SHORTENED)/FLOAT=D_FLOAT/object=DKA300:
    >> > >> >> > [AW.LIBXML2-2_6_30.DEBUG]HTMLTR
    >> > >> >> > EE.OBJ; HTMLTREE.C
    >> > >> >> > typedef long double trio_long_double_t;
    >> > >> >> > ........^
    >> > >> >> > %CC-I-LONGDOUBLENYI, In this declaration, type long double has the
    >> > >> >> > same
    >> > >> >> > representation as type double on this platform.
    >> > >> >> > At line number 156 in DKA300:
    >> > >> >> > [AW.LIBXML2-2_6_30]TRIODEF.H;1.

    >>
    >> > >> >> So? Whether that's a real problem depends on now many bits it
    >> > >> >> really
    >> > >> >> uses for trio_long_double_t variables. Without looking at the code, I
    >> > >> >> have no idea.

    >>
    >> > >> >Well, I can't tell. I've never dealed with the fp/fp_class stuff in my
    >> > >> >life so I just changed that
    >> > >> >long double to double (like it stated in the compiler message). I know
    >> > >> >it sounds naive, but
    >> > >> >I have no other clue yet.

    >>
    >> > >> $ HELP CC LANGUAGE DATA_TYPES...

    >>
    >> > >> float 32-bit (single-precision) floating-point number
    >> > >> double 64-bit (double-precision) floating-point number
    >> > >> long float Interchangeable with double, but usage is
    >> > >> obsolete

    >>
    >> You left out:
    >>
    >> long double 128-bit (double-precision) floating-point
    >> number
    >>
    >> which appears when I use the same help command you did with HP C
    >> V7.3-009 on OpenVMS Alpha V8.3 installed. For whatever reason, I don't
    >> think VAX C or DEC C on OpenVMS VAX ever implemented long double as an
    >> H_FLOAT, which would have been the natural thing to do (REAL*16 for you
    >> FORTRAN folks). But on 64-bit OpenVMS platforms with IEEE floating
    >> point enabled, long double does produce an X_FLOAT, which is twice as
    >> big as an ordinary double.
    >>
    >>
    >>
    >> > >> Perhaps, it's just an old coding hangover from when the datum was changed
    >> > >> from long float (which this above says is obsolete usage) to double. I'd
    >> > >> remove the 'long' or, if you want, conditionalize that for the VMS build.

    >>
    >> If it's conditionalized you definitely want to conditionalize it for
    >> VAX, not VMS, seeing as long double does give a double that twice as
    >> long as an ordinary double on 64-bit OpenVMS platforms.
    >>
    >> > Just recently I finished getting libxml2-2_4_27 to build on VAX with
    >> > both DEC C and VAX C for use with VMS Mosaic. The main issue I ran
    >> > into was the need for IEEE floating point; several functions depend
    >> > on IEEE behaviors which are not available on VAX. Fortunately, I do
    >> > not think Mosiac's usage of libxml2 will be affected by the lack of
    >> > these behaviors. I can zip up what I have and put it out for FTP.


    What I have will build on VAX.

    >> > If your application depends on the unavailable IEEE behaviors, then
    >> > you could be in for major problems. I'm not sure how much (or when)
    >> > libxml2 actually makes use of these behaviors.

    >>
    >> > As far as D_FLOAT vs. G_FLOAT, I used G_FLOAT because it is the closest
    >> > match for libxml2's use of IEEE floating point.

    >>
    >> Agreed. You'd almost certainly be better off with G_FLOAT since its
    >> range is much closer to IEEE than D_FLOAT's is. However, you should
    >> build with the same option that was used to build whatever you'll be
    >> linking with, such as Perl or WASD. And there is nothing corresponding
    >> to IEEE exception handling, NaNs, etc. Whether that causes trouble
    >> depends entirely on what XML you end up parsing. Validating against
    >> data-oriented schemas that do range checking or enforce other numeric
    >> rules will probably cause your parser to blow up spectacularly. But if
    >> you never see such schemas or attempt to do validation you'll probably
    >> be fine.
    >>
    >> On the fp_class problem:
    >>
    >> $ help crtl fp_class
    >>
    >> CRTL
    >>
    >> fp_class
    >>
    >> Determines the class of IEEE floating-point values.
    >>
    >> This function is OpenVMS Alpha and I64 only.
    >>
    >> In other words, its absence is important, but you can't get it on VAX,
    >> or at least not unless you want to roll your own IEEE floating point in
    >> software, including standard run-time library support for same.
    >>
    >> --
    >> Posted via a free Usenet account fromhttp://www.teranews.com

    >
    > Well, I even tried another port Hoff pointed me to, the libxml2-2-6-27
    > version and I aint getting
    > any step further. I get the same results like I had with the 30
    > subversion and even trying
    > an older version , like 2.4.x is not working out. It's all about the
    > fp_class and floating point
    > construcs/constants in the trio files. I have no clue, how they got
    > build on the vax, there's
    > even no diffs for VAX. The code-intern fallback method is also not
    > working and leads
    > to an access violation. When it comes to the link process of the
    > trionan test files
    > my compiler bails out with an bugcheck ....
    >
    > My main reason getting the libxml2 running on OpenVMS/VAX is to use
    > the
    > libxml perl modules for my dynamic XML/XSL homepage parser, a cms-
    > based perl/xml/xsl
    > construct I developed on linux. On linux tho it uses the Sablotron
    > Parser. I want to open
    > my OpenVMS hobby homepage with my VAX and therefore wanted to
    > implement that
    > dynamic perl homepage parser with WASD 9.2 server using perl rte
    > (which already runs
    > nicely).
    >
    > Unless nobody states me any solution for the libxml2, I will skip that
    > library, try to
    > get solved my c++ installation issues on my VAX and try to compile the
    > Sablotron
    > Parser to OpenVMS/VAX. That would be even a better solution, I would
    > not need
    > to change the perl cms code, that is already running.


    My offer to zip up the libxml2-2_4_27 port I have is still open (see
    above). It will build on VAX (even with GNU C). The TRIO stuff has
    been hacked to avoid IEEE and fp_class issues as much as possible.
    However, as previously pointed out, if your application depends on
    IEEE floating point (i.e., stuff like NAN), then no VAX libxml2 port
    is going to work properly (unless someone has an IEEE floating point
    emulation library for VAX).

    My port is designed to work with Mosaic, so the build only includes
    enough to compile and build an object library. It doesn't include
    any of the tests, docs, etc. If nothing else, it would show you
    what needs to be hacked in the TRIO files.


    George Cook
    WVNET

  12. Re: Building libxml2 on OpenVMS/VAX

    On 9 Jan., 08:26, "Andreas W. Wylach" wrote:
    > On 8 Jan., 04:39, "Craig A. Berry"
    > wrote:
    >
    >
    >
    > > In article <2UxR5LiUDSYl@wvnvms>, c...@wvnvms.wvnet.edu (George Cook)
    > > wrote:

    >
    > > > In article
    > > > , "Andreas
    > > > W. Wylach" writes:
    > > > > On 7 Jan., 14:02, VAXman- @SendSpamHere.ORG wrote:
    > > > >> In article
    > > > >> ,
    > > > >> "Andreas W. Wylach" writes:
    > > > >> >On 7 Jan., 11:58, s...@antinode.org (Steven M. Schweda) wrote:
    > > > >> >> From: "Andreas W. Wylach"

    >
    > > > >> >> > To my problem: Since 2 days I try to build the libxml2 library on my
    > > > >> >> > Vax (a VaxStation 4000/96 with
    > > > >> >> > OpenVMS 7.3 with Compaq C V6.4-005).

    >
    > > libxml2 is an outstanding hunk of software. If you don't need a
    > > validating parser, though, also consider expat.

    >
    > > > >> >> > CC/NAMES=(SHORTENED)/FLOAT=D_FLOAT/object=DKA300:
    > > > >> >> > [AW.LIBXML2-2_6_30.DEBUG]HTMLTR
    > > > >> >> > EE.OBJ; HTMLTREE.C
    > > > >> >> > typedef long double trio_long_double_t;
    > > > >> >> > ........^
    > > > >> >> > %CC-I-LONGDOUBLENYI, In this declaration, type long double has the
    > > > >> >> > same
    > > > >> >> > representation as type double on this platform.
    > > > >> >> > At line number 156 in DKA300:
    > > > >> >> > [AW.LIBXML2-2_6_30]TRIODEF.H;1.

    >
    > > > >> >> So? Whether that's a real problem depends on now many bits it
    > > > >> >> really
    > > > >> >> uses for trio_long_double_t variables. Without looking at the code, I
    > > > >> >> have no idea.

    >
    > > > >> >Well, I can't tell. I've never dealed with the fp/fp_class stuff in my
    > > > >> >life so I just changed that
    > > > >> >long double to double (like it stated in the compiler message). I know
    > > > >> >it sounds naive, but
    > > > >> >I have no other clue yet.

    >
    > > > >> $ HELP CC LANGUAGE DATA_TYPES...

    >
    > > > >> float 32-bit (single-precision) floating-point number
    > > > >> double 64-bit (double-precision) floating-point number
    > > > >> long float Interchangeable with double, but usage is
    > > > >> obsolete

    >
    > > You left out:

    >
    > > long double 128-bit (double-precision) floating-point
    > > number

    >
    > > which appears when I use the same help command you did with HP C
    > > V7.3-009 on OpenVMS Alpha V8.3 installed. For whatever reason, I don't
    > > think VAX C or DEC C on OpenVMS VAX ever implemented long double as an
    > > H_FLOAT, which would have been the natural thing to do (REAL*16 for you
    > > FORTRAN folks). But on 64-bit OpenVMS platforms with IEEE floating
    > > point enabled, long double does produce an X_FLOAT, which is twice as
    > > big as an ordinary double.

    >
    > > > >> Perhaps, it's just an old coding hangover from when the datum was changed
    > > > >> from long float (which this above says is obsolete usage) to double. I'd
    > > > >> remove the 'long' or, if you want, conditionalize that for the VMS build.

    >
    > > If it's conditionalized you definitely want to conditionalize it for
    > > VAX, not VMS, seeing as long double does give a double that twice as
    > > long as an ordinary double on 64-bit OpenVMS platforms.

    >
    > > > Just recently I finished getting libxml2-2_4_27 to build on VAX with
    > > > both DEC C and VAX C for use with VMS Mosaic. The main issue I ran
    > > > into was the need for IEEE floating point; several functions depend
    > > > on IEEE behaviors which are not available on VAX. Fortunately, I do
    > > > not think Mosiac's usage of libxml2 will be affected by the lack of
    > > > these behaviors. I can zip up what I have and put it out for FTP.

    >
    > > > If your application depends on the unavailable IEEE behaviors, then
    > > > you could be in for major problems. I'm not sure how much (or when)
    > > > libxml2 actually makes use of these behaviors.

    >
    > > > As far as D_FLOAT vs. G_FLOAT, I used G_FLOAT because it is the closest
    > > > match for libxml2's use of IEEE floating point.

    >
    > > Agreed. You'd almost certainly be better off with G_FLOAT since its
    > > range is much closer to IEEE than D_FLOAT's is. However, you should
    > > build with the same option that was used to build whatever you'll be
    > > linking with, such as Perl or WASD. And there is nothing corresponding
    > > to IEEE exception handling, NaNs, etc. Whether that causes trouble
    > > depends entirely on what XML you end up parsing. Validating against
    > > data-oriented schemas that do range checking or enforce other numeric
    > > rules will probably cause your parser to blow up spectacularly. But if
    > > you never see such schemas or attempt to do validation you'll probably
    > > be fine.

    >
    > > On the fp_class problem:

    >
    > > $ help crtl fp_class

    >
    > > CRTL

    >
    > > fp_class

    >
    > > Determines the class of IEEE floating-point values.

    >
    > > This function is OpenVMS Alpha and I64 only.

    >
    > > In other words, its absence is important, but you can't get it on VAX,
    > > or at least not unless you want to roll your own IEEE floating point in
    > > software, including standard run-time library support for same.

    >
    > > --
    > > Posted via a free Usenet account fromhttp://www.teranews.com

    >
    > Well, I even tried another port Hoff pointed me to, the libxml2-2-6-27
    > version and I aint getting
    > any step further. I get the same results like I had with the 30
    > subversion and even trying
    > an older version , like 2.4.x is not working out. It's all about the
    > fp_class and floating point
    > construcs/constants in the trio files. I have no clue, how they got
    > build on the vax, there's
    > even no diffs for VAX. The code-intern fallback method is also not
    > working and leads
    > to an access violation. When it comes to the link process of the
    > trionan test files
    > my compiler bails out with an bugcheck ....
    >
    > My main reason getting the libxml2 running on OpenVMS/VAX is to use
    > the
    > libxml perl modules for my dynamic XML/XSL homepage parser, a cms-
    > based perl/xml/xsl
    > construct I developed on linux. On linux tho it uses the Sablotron
    > Parser. I want to open
    > my OpenVMS hobby homepage with my VAX and therefore wanted to
    > implement that
    > dynamic perl homepage parser with WASD 9.2 server using perl rte
    > (which already runs
    > nicely).
    >
    > Unless nobody states me any solution for the libxml2, I will skip that
    > library, try to
    > get solved my c++ installation issues on my VAX and try to compile the
    > Sablotron
    > Parser to OpenVMS/VAX. That would be even a better solution, I would
    > not need
    > to change the perl cms code, that is already running.
    >
    > I have the expat running on my VAX, there was no problems at all, but
    > it's not enough
    > for my application. I need a parser that incorporates xml in my xsl
    > stylesheets and
    > expat wont do that for me the way I need it. I want to try not
    > to use lot's of perl modules and want to keep the perl Application as
    > small as possible
    > for performance reasons and try to keep the html generation under 5
    > seconds (on the VAX).
    > Even tho for calling content items I need the xpath functionality.
    > Without that the whole
    > thing is not working.
    >
    > An example for the my parser is my street-lights info/collection
    > homepage (http://www.street-lights.info), just if you guys want to
    > know what I
    > am talking about.-))
    >
    > Andreas W. Wylach


    The problem is solved with the help from George Cook's libxml2 Port to
    VAX. The
    compilation of the library went thru without any problems.

    Building the perl libxml module gave me some problems, had 3 undefined
    symbols
    due the length of a couple of function names, that exceeded 31 chars.
    I fixed that
    and now I can use the parser with my perl test construct. Just checked
    it out and
    it's also pretty fast with the rte envisonment of Wasd.
    Will see, how I can build up that homepage project. But for now I am
    happy.-)

    Thanks to all you guys that helped me out and tried to get me on the
    path!

    Andreas W. Wylach

+ Reply to Thread