agray wrote:
>
> >I intend to ultimately use SNACC as a compiler but using its template
> >output as the input to a converter to OpenSSL template format.
>
> yea - the one i noticed was the bitstr start. I'm having a hell of a
> time doing cvs updates recently - very poor connexns from home.
>
>I intend to ultimately use SNACC as a compiler but using its template
>output as the input to a converter to OpenSSL template format.
yea - the one i noticed was the bitstr start. I'm having a hell of a
time doing cvs updates recently - very poor connexns from home.
have you started this - i.e.
agray wrote:
>
> >2 or 3
>
> your time of course ;-)
>
> > And in any case, I personally wouldn't trust a shared OpenSL library
> > just yet. There are just too many things that are about to change...
>
> i've seen - i'm playing hell on keeping up on what's going on. You and
> Geoff on the
>2 or 3
your time of course ;-)
> And in any case, I personally wouldn't trust a shared OpenSL library
> just yet. There are just too many things that are about to change...
i've seen - i'm playing hell on keeping up on what's going on. You and
Geoff on the engine work as well as Steve starti
Always watch for -shared and the -expect_unresolved "*" for DigUnix ld
options. I was building api libraries against ssleay for Netscape
server 1-->2.x along time ago (3-5 yrs ago) and as i remember this was
necessary.
> I'm now pressing ahead on building OpenSSL/Apache/Mod_SSL *with* DSO Apache
Many thanks to Richard and Andrew, who explained a DigUnix box's behaviour
magnificently, and also to a bunch of other folks who emailed me direct to
explain the "-fPIC" stuff (which I now know is not relevant to DigUnix - it
generates relocatable code anyway).
I'm now pressing ahead on building
From: agray <[EMAIL PROTECTED]>
agray> Richard's spot on here. (he usually is, btw)
*pu*
agray> Always remember anything originating from, named like, "OSF"
agray> (my ex-employer) will have "anomolies". (DigUnix=OSF/1)
Heh...
[...]
agray> some thoughts and an outcome should be put onto d
Boyce, Nick wrote:
>
> Richard Levitte wrote :
>
> > nick.boyce> But what I don't understand is why you're talking about a
> > nick.boyce> problem with "-fPIC" when my compilation objected to
> > nick.boyce> "-std1" ...
> >
> > Ah. Well, I'll do some qualified guesses: suppose that the command
From: "Boyce, Nick" <[EMAIL PROTECTED]>
nick.boyce> Words fail me ... and this is a commercial big-bucks Unix ...
nick.boyce> Thanks for the analysis.
Heh.
nick.boyce> Erm ... I need to find a way forward on this.
Didn't you already? Just avoid using -fPIC on True64. Ah, yes, I
forgot to ans
Richard Levitte wrote :
> nick.boyce> But what I don't understand is why you're talking about a
> nick.boyce> problem with "-fPIC" when my compilation objected to
> nick.boyce> "-std1" ...
>
> Ah. Well, I'll do some qualified guesses: suppose that the command
> line parser in ld is the stupid k
From: "Boyce, Nick" <[EMAIL PROTECTED]>
nick.boyce> Richard> If you check the manual for ld, you'll probably
nick.boyce> Richard> find a few lines about '-f fil', where the
nick.boyce> Richard> filling is expected to be a 4-byte hex constant.
nick.boyce>
nick.boyce> Well you're quite right; the
I got two replies :-
Richard Levitte said :
Richard> Well, it looks like Compaq C will just ignore -fPIC when it
compiles,
Richard> and try to pass it on to ld when linking is going on. However,
Richard> there's no support for -fPIC anywhere in True64.
[ Thanks Richard: I have no idea *what*
From: "Boyce, Nick" <[EMAIL PROTECTED]>
nick.boyce> I've just had a go at building OpenSSL 0.9.5a on our
nick.boyce> Digital Unix box, but the build fails, apparently with a
nick.boyce> bizarre parameter error in a linker call, thus :
nick.boyce> ===< cut >
nic
I've just had a go at building OpenSSL 0.9.5a on our Digital Unix box, but
the build fails, apparently with a bizarre parameter error in a linker call,
thus :
===< cut >
cc -DMONOLITH -I../include -DNO_IDEA -fPIC -std1 -tune host -O4
-readonly_st
14 matches
Mail list logo
