Bug report: ruby-1.8.0p3 fails to compile under FreeBSD-4.7

ruby-talk
1

gcc -fPIC -g -O2 -DDB_DBM_HSEARCH -DDBM_HDR="<db.h>" -I. -I/u/home/telinco/build/ruby/ruby-1.8.0 -I/u/home/telinco/build/ruby/ruby-1.8.0 -I/u/home/telinco/build/ruby/ruby-1.8.0/ext/dbm -DHAVE_DB_H -DHAVE_SYS_CDEFS_H -DHAVE___DB_NDBM_OPEN -DHAVE___DB_NDBM_CLEARERR -c dbm.c
dbm.c:29: syntax error before DBM' dbm.c: In function free_dbm’:
dbm.c:49: structure has no member named di_dbm' dbm.c:49: structure has no member named di_dbm’
dbm.c: In function fdbm_close': dbm.c:60: structure has no member named di_dbm’
dbm.c:61: structure has no member named di_dbm' dbm.c:62: structure has no member named di_dbm’
dbm.c: In function fdbm_initialize': dbm.c:82: DBM’ undeclared (first use in this function)
dbm.c:82: (Each undeclared identifier is reported only once
dbm.c:82: for each function it appears in.)
dbm.c:82: dbm' undeclared (first use in this function) dbm.c:83: syntax error before struct’
dbm.c:87: mode' undeclared (first use in this function) dbm.c:113: dbmp’ undeclared (first use in this function)
<<< snip more similar errors >>>

On this box, DBM is defined in /usr/include/ndbm.h:

typedef DB DBM;

It in turn includes <db.h>, which defines DB and DBT.

Editing the ext/dbm/Makefile manually, so that it has -DDBM_HDR="<ndbm.h>",
allows the compile to continue.

ext/dbm/mkmf.log is attached.

Regards,

Brian.

mkmf.log (1.94 KB)

2

Another (possible) problem with ruby-1.8.0p3

When I build under FreeBSD-4.7 (working around the dbm problem as outlined
before), and then install, libruby doesn’t seem to get installed:

$ find /usr/local/lib/ruby/1.8 -name ‘libruby*’
$

But it was installed when I build 1.6.8:

$ find /usr/local/lib/ruby/1.6 -name ‘libruby*’
/usr/local/lib/ruby/1.6/i386-freebsd4.7/libruby.a
$

Is this intentional, or has something gone wrong?

Cheers,

Brian.

3

Hi,

···

At Wed, 23 Jul 2003 00:20:39 +0900, Brian Candler wrote:

On this box, DBM is defined in /usr/include/ndbm.h:

typedef DB DBM;

It in turn includes <db.h>, which defines DB and DBT.

Editing the ext/dbm/Makefile manually, so that it has -DDBM_HDR=“<ndbm.h>”,
allows the compile to continue.

Does this patch work?

Index: lib/mkmf.rb

RCS file: /cvs/ruby/src/ruby/lib/mkmf.rb,v
retrieving revision 1.138
diff -u -2 -p -r1.138 mkmf.rb
— lib/mkmf.rb 23 Jul 2003 05:19:22 -0000 1.138
+++ lib/mkmf.rb 23 Jul 2003 06:35:30 -0000
@@ -250,4 +250,58 @@ def cpp_include(header)
end

+def try_static_assert(expr, headers = nil, opt = “”)

  • headers = cpp_include(headers)
  • try_compile(<<SRC, opt)
    +#{COMMON_HEADERS}
    +#{headers}
    +int tmp[(#{expr}) ? 1 : -1];
    +SRC
    +end

+def try_constant(const, headers = nil, opt = “”)

  • if true # CROSS_COMPILING
  • unless try_compile(<<“SRC”, opt)
    +#{COMMON_HEADERS}
    +#{cpp_include(headers)}
    +int tmp = #{const};
    +SRC
  •  return nil
  • end
  • if try_static_assert(“#{const} < 0”, headers, opt)
  •  neg = true

  •  const = "-(#{const})"
  • elsif try_static_assert(“#{const} == 0”, headers, opt)
  •  return 0
  • end
  • upper = 1
  • until try_static_assert(“#{const} < #{upper}”, headers, opt)
  •  lower = upper

  •  upper <<= 1
  • end
  • return nil unless lower
  • until try_static_assert(“#{const} == #{upper}”, headers, opt)
  •  if try_static_assert("#{const} > #{(upper+lower)/2}", headers, opt)

  •    lower = (upper+lower)/2

  •  else

  •    upper = (upper+lower)/2

  •  end
  • end
  • upper = -upper if neg
  • return upper
  • else
  • src = %{#{COMMON_HEADERS}
    +#{cpp_include(headers)}
    +#include <stdio.h>
    +int main() {printf(“%d\n”, (int)(#{const})); return 0;}
    +}
  • if try_link0(src, opt)
  •  xpopen("./conftest") do |f|

  •    return Integer(f.gets)

  •  end
  • end
  • end
  • nil
    +end

def try_func(func, libs, headers = nil)
headers = cpp_include(headers)
@@ -443,4 +497,36 @@ SRC
end

+def have_type(type, header=nil, opt=“”)

  • checking_for type do
  • if try_compile(<<“SRC”, opt) or try_compile(<<“SRC”, opt)
    +#{COMMON_HEADERS}
    +#{cpp_include(header)}
    +static #{type} t;
    +SRC
    +#{COMMON_HEADERS}
    +#{cpp_include(header)}
    +static #{type} *t;
    +SRC
  •  $defs.push(format("-DHAVE_TYPE_%s", type.upcase))

  •  true
  • else
  •  false
  • end
  • end
    +end

+def check_sizeof(type, header=nil)

  • expr = “sizeof(#{type})”
  • m = "checking size of #{type}… "
  • message “%s”, m
  • Logging::message “check_sizeof: %s--------------------\n”, m
  • if size = try_constant(expr, header)
  • $defs.push(format(“-DSIZEOF_%s”, type.upcase))
  • end
  • message(a = size ? “#{size}\n” : “failed\n”)
  • Logging::message “-------------------- %s\n”, a
  • r
    +end

def find_executable0(bin, path = nil)
path = (path || ENV[‘PATH’]).split(File::PATH_SEPARATOR)
Index: ext/dbm/extconf.rb

RCS file: /cvs/ruby/src/ruby/ext/dbm/extconf.rb,v
retrieving revision 1.15
diff -u -2 -p -r1.15 extconf.rb
— ext/dbm/extconf.rb 7 Jul 2003 01:30:02 -0000 1.15
+++ ext/dbm/extconf.rb 23 Jul 2003 06:37:03 -0000
@@ -33,5 +33,5 @@ def db_check(db)
if have_library(db, db_prefix(“dbm_open”)) || have_func(db_prefix(“dbm_open”))
for hdr in $dbm_conf_headers.fetch(db, [“ndbm.h”])

  •  if have_header(hdr.dup)

  •  if have_header(hdr.dup) and have_type("DBM", hdr.dup, hsearch)
    $CFLAGS += " " + hsearch + ‘-DDBM_HDR="<’+hdr+‘>"’
    return true

–
Nobu Nakada

4

Hi,

···

At Wed, 23 Jul 2003 02:52:44 +0900, Brian Candler wrote:

When I build under FreeBSD-4.7 (working around the dbm problem as outlined
before), and then install, libruby doesn’t seem to get installed:

$ find /usr/local/lib/ruby/1.8 -name ‘libruby*’
$

But it was installed when I build 1.6.8:

$ find /usr/local/lib/ruby/1.6 -name ‘libruby*’
/usr/local/lib/ruby/1.6/i386-freebsd4.7/libruby.a
$

There should be libruby-static.a at /usr/local/lib.

–
Nobu Nakada

5

Yes: it happily compiles from start to end, and dbm.so is created. Many
thanks.

I wasn’t aware of this module before, since it’s not mentioned in the
Pickaxe. Very cool. I tested it by making a small dbm file in 1.6.8 and
reading it in 1.8.0p3, and it seems fine.

Incidentally, I note there is a method DBM#to_hash. This sets a precedent
for having Array#to_hash as discussed previously :slight_smile:

Regards,

Brian.

···

On Wed, Jul 23, 2003 at 03:40:31PM +0900, nobu.nokada@softhome.net wrote:

Brian Candler wrote:

On this box, DBM is defined in /usr/include/ndbm.h:

typedef DB DBM;

It in turn includes <db.h>, which defines DB and DBT.

Editing the ext/dbm/Makefile manually, so that it has -DDBM_HDR=“<ndbm.h>”,
allows the compile to continue.

Does this patch work?

6

Ah, there it is. But this now seems inconsistent. If you’re going to put the
library in /usr/local/lib, surely ruby.h should be installed in
/usr/local/include?

I actually liked it as it was - since I’m just starting to play with 1.8.0,
having both versions in separate places makes it easy to link against one
versus the other. But in future this won’t be possible.

Also - I don’t get a .so. Is that a platform limitation, or a compile-time
option? Any reason not to build it by default?

Regards,

Brian.

···

On Wed, Jul 23, 2003 at 12:33:58PM +0900, nobu.nokada@softhome.net wrote:

At Wed, 23 Jul 2003 02:52:44 +0900, > Brian Candler wrote:

When I build under FreeBSD-4.7 (working around the dbm problem as outlined
before), and then install, libruby doesn’t seem to get installed:

$ find /usr/local/lib/ruby/1.8 -name ‘libruby*’
$

But it was installed when I build 1.6.8:

$ find /usr/local/lib/ruby/1.6 -name ‘libruby*’
/usr/local/lib/ruby/1.6/i386-freebsd4.7/libruby.a
$

There should be libruby-static.a at /usr/local/lib.

7

Hi,

···

In message “Re: Bug report: ruby-1.8.0p3 fails to compile under FreeBSD-4.7” on 03/07/23, Brian Candler B.Candler@pobox.com writes:

Incidentally, I note there is a method DBM#to_hash. This sets a precedent
for having Array#to_hash as discussed previously :slight_smile:

“to_hash” is a method used by implicit conversion, like “to_str”.

						matz.
8

Hi,

There should be libruby-static.a at /usr/local/lib.

Ah, there it is. But this now seems inconsistent. If you’re going to put the
library in /usr/local/lib, surely ruby.h should be installed in
/usr/local/include?

Maybe, /usr/local/include/ruby-1.8? Or, as you mentioned,
multiple versions won’t be possible to coexist.

I actually liked it as it was - since I’m just starting to play with 1.8.0,
having both versions in separate places makes it easy to link against one
versus the other. But in future this won’t be possible.

–program-prefix, --program-suffix and --program-transform-name
can change the name.

Also - I don’t get a .so. Is that a platform limitation, or a compile-time
option? Any reason not to build it by default?

libruby.so? Try configure with --enable-shared.

···

At Wed, 23 Jul 2003 19:55:25 +0900, Brian Candler wrote:

–
Nobu Nakada

9

Ah, there it is. But this now seems inconsistent. If you’re going to put the
library in /usr/local/lib, surely ruby.h should be installed in
/usr/local/include?

Maybe, /usr/local/include/ruby-1.8? Or, as you mentioned,
multiple versions won’t be possible to coexist.

But same applies to /usr/local/lib/libruby-static.a

I’m sure this has been discussed before at length before the decision was
made to change it. But to me it seems to be consistent then both the library
and headers should be in the same system-expected place: either

(1)
/usr/local/lib/libruby[-static].a
/usr/local/include/ruby.h

OR

(2)
/usr/local/lib/ruby/1.8/i386-freebsd-4.7/ruby.h
libruby[-static].a
(as it was for 1.6.8)
OR

(3) like (2), but with symlinks from the first place to the second.

Also, why “libruby-static.a” instead of “libruby.a” ? I don’t know of
anything else that uses a different name for the .a and the .so.

$ ls -l /usr/lib/libc.*
-r–r–r-- 1 root wheel 1213072 Mar 31 01:16 /usr/lib/libc.a
lrwxrwxrwx 1 root wheel 9 May 19 21:19 /usr/lib/libc.so → libc.so.4
-r–r–r-- 1 root wheel 567860 Mar 31 01:16 /usr/lib/libc.so.4

Also - I don’t get a .so. Is that a platform limitation, or a compile-time
option? Any reason not to build it by default?

libruby.so? Try configure with --enable-shared.

Ah thanks, I got it now: /usr/local/lib/libruby.so[.18].

Thanks,

Brian.

···

On Thu, Jul 24, 2003 at 03:26:49PM +0900, nobu.nokada@softhome.net wrote:

10

Hi,

Ah, there it is. But this now seems inconsistent. If you’re going to put the
library in /usr/local/lib, surely ruby.h should be installed in
/usr/local/include?

Maybe, /usr/local/include/ruby-1.8? Or, as you mentioned,
multiple versions won’t be possible to coexist.

But same applies to /usr/local/lib/libruby-static.a

A difference is, header name is not easily changeable, but
library is. The formar is coded in many sources whereas the
latter is decided by configuration and supplied by a file,
rbconfig.rb. So what we can do about headers is moving
directory and providing there by -I option.

Some other projects install their headers under particular (and
even version specific) directories, freetype, glib, gdk, gtk,
gnome family, php, python, wine and so on.

I’m sure this has been discussed before at length before the decision was
made to change it. But to me it seems to be consistent then both the library
and headers should be in the same system-expected place: either

(1)
/usr/local/lib/libruby[-static].a
/usr/local/include/ruby.h

OR

(2)
/usr/local/lib/ruby/1.8/i386-freebsd-4.7/ruby.h
libruby[-static].a
(as it was for 1.6.8)
OR

(3) like (2), but with symlinks from the first place to the second.

I prefer (1) with modified as above. A problem about (3) would
be there are platforms don’t have symlinks.

Also, why “libruby-static.a” instead of “libruby.a” ? I don’t know of
anything else that uses a different name for the .a and the .so.

For the case of linking ruby statically, by -lruby-static. For
instance, try_link and try_run mkmf.rb need to run linked
programs, so if they are linked dynamically, they cannot be run
unless libruby.so get installed.

···

At Fri, 25 Jul 2003 07:11:32 +0900, Brian Candler wrote:

–
Nobu Nakada