On Thu July 24 2003 4:03 am, Yukihiro Matsumoto wrote:
I’m sure we still have problems left. Braves, try and find errors, on
as many platforms as possible, please.
Compiling on RedHat 9:
gcc -fPIC -g -O2 -I. -I/usr/local/ruby-1.8.0 -I/usr/local/ruby-1.8.0
-I/usr/local/ruby-1.8.0/ext/openssl -DHAVE_OPENSSL_CRYPTO_H -DHAVE_UNISTD_H
-DHAVE_SYS_TIME_H -DHAVE_EVP_MD_CTX_CREATE -DHAVE_EVP_MD_CTX_CLEANUP
-DHAVE_EVP_MD_CTX_DESTROY -DHAVE_PEM_DEF_CALLBACK -DHAVE_EVP_MD_CTX_INIT
-DHAVE_HMAC_CTX_INIT -DHAVE_HMAC_CTX_CLEANUP -DHAVE_X509_CRL_SET_VERSION
-DHAVE_X509_CRL_SET_ISSUER_NAME -DHAVE_X509_CRL_SORT
-DHAVE_X509_CRL_ADD0_REVOKED -DHAVE_CONF_GET1_DEFAULT_CONFIG_FILE
-DHAVE_BN_MOD_SQR -DHAVE_BN_MOD_ADD -DHAVE_BN_MOD_SUB
-DHAVE_CONF_GET1_DEFAULT_CONFIG_FILE -DHAVE_VA_ARGS_MACRO
-DHAVE_OPENSSL_OCSP_H -DHAVE_ST_FLAGS -DHAVE_RB_OBJ_INIT_COPY -c ossl.c
In file included from /usr/include/openssl/ssl.h:179,
from ossl.h:34,
from ossl.c:11:
/usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory
In file included from /usr/include/openssl/ssl.h:179,
from ossl.h:34,
from ossl.c:11:
/usr/include/openssl/kssl.h:132: parse error before “krb5_enctype”
/usr/include/openssl/kssl.h:134: parse error before “FAR”
…
It looks like /usr/kerberos/include isn’t in the include path. Configure
should probably catch that, right? I configured it as ./configure
–prefix=/usr/local/ruby-1.8.0-preview4
Btw, would it make sense to change the top-level directory in the tar file to
“ruby-1.8.0-src” so that if people want to install to /usr/local/ruby-1.8.0
they can do so more easily?
This is basically RedHat’s screwup, as far as I’m concerned. Pretty well
every app I’ve tried to build under RedHat 9, which uses OpenSSL, has
broken on the build in the same fashion (and I’ve had to manually
include the kerberos include dir). I think it’s because previously
(RedHat 8.0 and under) OpenSSL did not have a dependency on Kerberos…
At Fri, 25 Jul 2003 04:40:29 +0900, Ben Giddings wrote:
It looks like /usr/kerberos/include isn’t in the include path. Configure
should probably catch that, right? I configured it as ./configure
–prefix=/usr/local/ruby-1.8.0-preview4
CVS HEAD uses pkg-config if available.
Or, configure with
–with-openssl-include=/usr/kerberos/include
ossl_config.c:147: bad macro argument list
ossl_config.c:147: bad macro argument list
Hey, I recognize that! Saw it just last night!
Here’s my write-up and fix for it.
Ruby 1.8.0 preview4
Mac OS X 10.2.3
Bug in ‘ext/opensll’ extension:
It incorrectly configures HAVE_VA_ARGS_MACRO,
causing the build to fail with errors from ‘cpp’.
In ‘extconf.rb’, a test defines a macro for VA_ARGS,
but doesn’t invoke the macro, so it never gets expanded or evaluated.
Adding some dummy code to actually use the macro
is needed to test for VA_ARGS. (I think. Yes?)
Anyway, with a slight change, it configures without HAVE_VA_ARGS_MACRO,
and the extension (and everything else) builds to completion.
A one-line patch for ‘extconf.rb’ follows.
105c105
< if try_cpp("#define FOO(a, …) foo(a, ##VA_ARGS)\n int x() { FOO(1,2); }
")
···
if try_cpp(“#define FOO(a, …) foo(a, ##VA_ARGS)\n”)
(Now, to figure out how to tell ‘tcltklib’ about ‘-framework Tcl’…
and the same with ‘readline’… I think I still have the notes from last time!)
/usr/local/lib/ruby/1.8/tk.rb:940: warning: method redefined;
discarding old chooseDirectory
/usr/local/lib/ruby/1.8/tk.rb:1487:in const_missing': \ uninitialized constant Tk::Encoding::INTERP (NameError) from /usr/local/lib/ruby/1.8/tk.rb:1487:in encoding=’
from /usr/local/lib/ruby/1.8/tk.rb:1522
from -e:1:in `require’
from -e:1
Lyle, I tried to build 1.0.24 against the Ruby 1.8.0 pre 7 and I get a marco
error on “connect”. It appears the macro is defined in Win32.h from ruby
and conflights with the connect function in FXDatatarget.h.
Find below the results of building preview4 on HP-UX;
I fiddled a bit with those (important!!) sha2 warnings and I have a
feeling I’m missing something obvious. Can’t get it to work
Hmm, it seems HP-UX compiler does not provide sane definition of
uint64_t. I don’t know how to fix this. Anyone?
It does define it. But somehow it doesn’t get through to sha2.c
I can compile a testfile containing
uint64_t value = (uint64_t)0x1234567812345678;
just fine. So I’m probably doing something stupid. Maybe I should try with
a fresh untar (though I’ve typed make clean and removed the Makefiles in
all ext/ directories). I’ll try again tomorrow.
It is. That’s what I meant… that debugging symbols are included. It gets a
lot smaller if you strip them - under FreeBSD, about half size. I guess the
end-user or packager can choose that if they wish.
Cheers,
Brian.
···
On Fri, Jul 25, 2003 at 01:42:24AM +0900, Yukihiro Matsumoto wrote:
In message “Re: ruby 1.8.0 preview4” > on 03/07/24, Brian Candler B.Candler@pobox.com writes:
Updating to gcc 3.3 solves this problem on OS X (via Apple’s gcc 3.3
updater)
-Brian
···
On Thursday, July 24, 2003, at 03:51 PM, Brian McCallister wrote:
$gcc -v
Apple Computer, Inc. GCC version 1175, based on gcc version 3.1
20020420 (prerelease)
On Thursday, July 24, 2003, at 03:50 PM, Brian McCallister wrote:
ossl_config.c:147: bad macro argument list
ossl_config.c:147: bad macro argument list
cpp-precomp: warning: errors during smart preprocessing, retrying in
basic mode
:1:1: no macro name given in #define directive
make[1]: *** [ossl_config.o] Error 1
make: *** [all] Error 1
Darwin Kernel Version 6.6: Thu May 1 21:48:54 PDT 2003;
root:xnu/xnu-344.34.obj~1/RELEASE_PPC Power Macintosh powerpc
OS X 10.2.[whatever current is]
-Brian
On Thursday, July 24, 2003, at 04:03 AM, Yukihiro Matsumoto wrote:
Hello,
I just put preview4 archive on the ftp server.
I’m sure we still have problems left. Braves, try and find errors,
on
as many platforms as possible, please.
At Fri, 25 Jul 2003 04:11:15 +0900, Aredridel wrote:
I still had to apply the patch for ncurses’ location. It’s attached –
it can probably go in the main tree without problems.
I cannot understand the reason for the patch. Even if libtinfo
is necessary to use tgetent(), ext/curses/extconf.rb already
checks it so that the library would be linked. Am I missing
something?
In message “Re: ruby 1.8.0 preview4” on 03/07/25, Brian Candler B.Candler@pobox.com writes:
It is. That’s what I meant… that debugging symbols are included. It gets a
lot smaller if you strip them - under FreeBSD, about half size. I guess the
end-user or packager can choose that if they wish.
Packager can easily choose that, by modifying Makefile, or supplying
CFLAGS to configure.
Got it, patch below (both +Z for Tk and fix for digest/sha2). I am not
sure whether this sha-fix might break sha on old HP-UX systems.
I have easy access to all extensions, except gdbm openssl readline (which
are not installed on our system). The rest at least compiles fine, but I
haven’t tested them.
At Fri, 25 Jul 2003 04:11:15 +0900, > Aredridel wrote:
I still had to apply the patch for ncurses’ location. It’s attached –
it can probably go in the main tree without problems.
I cannot understand the reason for the patch. Even if libtinfo
is necessary to use tgetent(), ext/curses/extconf.rb already
checks it so that the library would be linked. Am I missing
something?
–
/ Alexander Bokovoy
the curls in your keyboard cord are losing electricity.
