[#4076] Ruby/DL — Jamis Buck <jamis_buck@...>

I recently used Ruby/DL to create bindings to the SQLite3 embedded

40 messages 2005/01/03
[#4096] Re: Ruby/DL — Paul Brannan <pbrannan@...> 2005/01/04

On Tue, Jan 04, 2005 at 02:53:49AM +0900, Jamis Buck wrote:

[#4099] Re: Ruby/DL — ts <decoux@...> 2005/01/04

>>>>> "P" == Paul Brannan <pbrannan@atdesk.com> writes:

[#4119] Re: Ruby/DL — Paul Brannan <pbrannan@...> 2005/01/05

On Wed, Jan 05, 2005 at 03:05:48AM +0900, ts wrote:

[#4120] Re: Ruby/DL — ts <decoux@...> 2005/01/05

>>>>> "P" == Paul Brannan <pbrannan@atdesk.com> writes:

[#4125] Re: Ruby/DL — Paul Brannan <pbrannan@...> 2005/01/05

On Thu, Jan 06, 2005 at 01:10:34AM +0900, ts wrote:

[#4116] Test::Unit::Collector::Dir won't work with code that modifies $LOAD_PATH — Eric Hodel <drbrain@...7.net>

Any test code that depends upon modifications of $: fails when used

10 messages 2005/01/05

[#4146] The face of Unicode support in the future — Charles O Nutter <headius@...>

Hello Rubyists!

47 messages 2005/01/06
[#4152] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/07

Hi,

[#4167] Re: The face of Unicode support in the future — Christian Neukirchen <chneukirchen@...> 2005/01/09

Yukihiro Matsumoto <matz@ruby-lang.org> writes:

[#4175] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/10

Hi,

[#4186] Re: The face of Unicode support in the future — Paul Brannan <pbrannan@...> 2005/01/11

On Mon, Jan 10, 2005 at 11:53:48PM +0900, Yukihiro Matsumoto wrote:

[#4192] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/12

Hi,

[#4269] Re: The face of Unicode support in the future — Wes Nakamura <wknaka@...>

19 messages 2005/01/18
[#4270] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/18

Hi,

[#4275] Re: The face of Unicode support in the future — Wes Nakamura <wknaka@...> 2005/01/19

[#4323] test/unit doesn't rescue a Exception — Tanaka Akira <akr@...17n.org>

test/unit doesn't rescue a Exception in a test method, as follows.

14 messages 2005/01/27
[#8773] Re: test/unit doesn't rescue a Exception — Tanaka Akira <akr@...> 2006/09/02

In article <87is5jb46q.fsf@serein.a02.aist.go.jp>,

[#8776] Re: test/unit doesn't rescue a Exception — "Nathaniel Talbott" <ntalbott@...> 2006/09/03

On 9/1/06, Tanaka Akira <akr@fsij.org> wrote:

[#8777] Re: test/unit doesn't rescue a Exception — Eric Hodel <drbrain@...7.net> 2006/09/03

On Sep 2, 2006, at 6:34 PM, Nathaniel Talbott wrote:

Building ruby 1.8.2 with static extensions on Windows XP

From: "David Craine" <dave@...>
Date: 2005-01-20 04:57:41 UTC
List: ruby-core #4290
I have been trying to build ruby 1.8.2 on Windows XP and attempting to get
the extensions linked statically.  I've commented in the extension names
listed in the Setup file in the ext dir; however, when the nmake process
gets to the point of creating the ruby.exe and rubyw.exe files it spits out
a fatal error as follows:

 

making ruby.exe, rubyw.exe

 

Microsoft (R) Program Maintenance Utility Version 7.10.3077

Copyright (C) Microsoft Corporation.  All rights reserved.

 

        rc -I. -I.  -I../ruby-1.8.2/win32 -r -fomsvcrt-ruby18.res
msvcrt-ruby18.rc

 

        cl -nologo -LD main.obj  msvcrt-ruby18-static.lib msvcrt-ruby18.res
oldnames.lib user32.lib advapi32.lib wsock32.lib advapi32.lib kernel32.lib
wsock32.lib user32.lib uuid.lib oleaut32.lib ole32.lib  -Femsvcrt-ruby18.dll
-link -incremental:no -debug -opt:ref -opt:icf -link -incremental:no -debug
-opt:ref -opt:icf -dll  -def: -link -incremental:no -debug -opt:ref -opt:icf
-dll  -def: -link -incremental:no -debug -opt:ref -opt:icf -dll  -def: -link
-incremental:no -debug -opt:ref -opt:icf -dll  -def: -link -incremental:no
-debug -opt:ref -opt:icf -dll  -def: -link -incremental:no -debug -opt:ref
-opt:icf -dll  -def: -link -incremental:no -debug -opt:ref -opt:icf -dll
-def: -link -incremental:no -debug -opt:ref -opt:icf -dll  -def: -link
-incremental:no -debug -opt:ref -opt:icf -dll

-def: -link -incremental:no -debug -opt:ref -opt:icf -dll  -def: -link
-incremental:no -debug -opt:ref -opt:icf -dll  -def: -link -incremental:no
-debug -opt:ref -opt:icf -dll  -def: -link -incremental:no -debug -opt:ref
-opt:icf -dll  -def: -link -incremental:no -debug -opt:ref -opt:icf -dll
-def: -link -incremental:no -debug -opt:ref -opt:icf -dll  -def: -link
-incremental:no -debug -opt:ref -o

pt:icf -dll  -def: -link -incremental:no -debug -opt:ref -opt:icf -dll
-def: -link -incremental:no -debug -opt:ref -opt:icf -dll  -def: -link
-incremental:no -debug -opt:ref -opt:icf -dll  -def: -def:msvcrt-ruby18.def

LINK : warning LNK4044: unrecognized option '/link'; ignored

LINK : fatal error LNK1146: no argument specified with option '/def:'

NMAKE : fatal error U1077: 'cl' : return code '0x2'

Stop.

NMAKE : fatal error U1077: '.\miniruby.exe' : return code '0x2'

Stop.

 

The 'cl' line looks like something got mis-generated in the make file.  I've
been successful in building the dynamically linked version of ruby, just not
the static one.

 

My ultimate goal is to embed ruby into my own executable and to statically
link in the extensions there; but I wanted to see how ruby did it first.
Any ideas on what this problem may be?

 

Dave Craine

In This Thread

Prev Next