Cext build failure

Decided to quickly checkout the cext branch on got a build
error…likely a pilot error…suggestions?

Jon

[C:\Users\Jon\Documents\JavaDev\jruby]echo %PATH%
C:\ant\bin;C:\Program Files\CollabNet\Subversion
Client;C:\Windows\system32;C:\W
indows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\P
rogram Files\ATI
Technologies\ATI.ACE\Core-Static;C:\tools;C:\Python27\Scripts;C
:\Python27;C:\ruby187\bin;c:\scala\bin;C:\gnuwin32\curl\bin;C:\gnuwin32\diff\bin
;C:\gnuwin32\grep\bin;C:\gnuwin32\findutils\bin;C:\gnuwin32\sed\bin;C:\gnuwin32
less\bin;C:\gnuwin32\upx\bin;C:\Program Files\Wix;C:\git\cmd

[C:\Users\Jon\Documents\JavaDev\jruby]echo %JAVA_HOME%
C:\Program Files\Java\jdk1.6.0_21

[C:\Users\Jon\Documents\JavaDev\jruby]git br -v

  • cext 4b28b4b mark two potential segfaults
    master f740f78 Fix JRUBY-4777 - LOG_NODELAY should have been
    LOG_NDELAY.

[C:\Users\Jon\Documents\JavaDev\jruby]ant clean build-jruby-cext-native

jar-complete:
[mkdir] Created dir:
C:\Users\Jon\Documents\JavaDev\jruby\build\jar-complete\META-INF\jruby.home
[copy] Copying 1343 files to
C:\Users\Jon\Documents\JavaDev\jruby\build\jar-complete\META-INF\jruby.home

BUILD FAILED
C:\Users\Jon\Documents\JavaDev\jruby\build.xml:443:
C:\Users\Jon\Documents\JavaDev\jruby\lib\native does not exist.

Total time: 33 seconds
C:\ant\bin\ant.bat [199] Usage : COLOR [BRIght] fg ON [BRIght] bg


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Try “ant clean cext” on current cext head. I just added that as a
shorter target to run, and juggled dependencies a little bit.

The lib/native dir should be created during the normal JRuby build, by
copying the jffi-related libraries there. I deleted that dir, ran “ant
clean cext” and it appears to build ok.

  • Charlie

On Tue, Aug 10, 2010 at 1:51 PM, Jon [email protected] wrote:

;C:\gnuwin32\grep\bin;C:\gnuwin32\findutils\bin;C:\gnuwin32\sed\bin;C:\gnuwin32\

Total time: 33 seconds
C:\ant\bin\ant.bat [199] Â Usage : COLOR [BRIght] fg ON [BRIght] bg


To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On Thu, Aug 12, 2010 at 4:37 PM, Jon [email protected] wrote:

Almost…Windows doesn’t like many of build.xml’s and doesn’t like the CC in Makefile.

Ahh, I didn’t even notice you were on Windows. Yeah…that’s a challenge
:slight_smile:

The attached patch to build.xml got me a bit farther, but I still get the following build failure…barfs that it’s missing sys/select.h. Â Will try to get some more time to look at it later.

Ok, I’ll make sure Tim sees this and we’ll get it incorporated into
the branch. We obviously want C exts to work on Windows like they do
anywhere else, though we’ll probably build and ship a pre-made binary
for release (but of course, we have to be able to build that binary
too).

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Try “ant clean cext” on current cext head. I just added that as a
shorter target to run, and juggled dependencies a little bit.

The lib/native dir should be created during the normal JRuby build, by
copying the jffi-related libraries there. I deleted that dir, ran “ant
clean cext” and it appears to build ok.

  • Charlie

Almost…Windows doesn’t like many of build.xml’s and doesn’t
like the CC in Makefile.

The attached patch to build.xml got me a bit farther, but I still get
the following build failure…barfs that it’s missing sys/select.h.
Will try to get some more time to look at it later.


[exec] gcc -DNDEBUG -O2 -fno-omit-frame-pointer -fno-strict-aliasing -W
-Wall
-Wno-unused -Wno-parentheses -Werror -Wundef
-I"/c/Users/Jon/Documents/JavaDe
v/jruby/cext/src/…/…//build"
-I"/c/Users/Jon/Documents/JavaDev/jruby/cext/src"
-I"/c/Users/Jon/Documents/JavaDev/jruby/cext/src/…/…//build"/jni
-I"/c/Users/
Jon/Documents/JavaDev/jruby/cext/src"/include
-I"/c/Users/Jon/Documents/JavaDev/
jruby/cext/src"/include/ruby -I"C:\Program
Files\Java\jdk1.6.0_21/include" -I"C
:\Program Files\Java\jdk1.6.0_21/include/win32" -D_REENTRANT
-D_LARGEFILE64_SOU
RCE -D_GNU_SOURCE -mwin32 -D_JNI_IMPLEMENTATION_ -c
/c/Users/Jon/Documents/JavaD
ev/jruby/cext/src/st.c -o
/c/Users/Jon/Documents/JavaDev/jruby/cext/src/…/…//b
uild/st.o
[exec] In file included from
c:/Users/Jon/Documents/JavaDev/jruby/cext/src/
include/ruby.h:2:0,
[exec] from
c:/Users/Jon/Documents/JavaDev/jruby/cext/src/
st.c:5:
[exec]
c:/Users/Jon/Documents/JavaDev/jruby/cext/src/include/ruby/ruby.h:27
:24: fatal error: sys/select.h: No such file or directory
[exec] compilation terminated.
[exec] make: ***
[/c/Users/Jon/Documents/JavaDev/jruby/cext/src/…/…//buil
d/st.o] Error 1

BUILD FAILED
C:\Users\Jon\Documents\JavaDev\jruby\build.xml:1520: exec returned: 2

too).
Let me find some time to get my head around this and get you a real
patch.

This is the known missing sys/select.h issue on mingw. It’s been such a
long time that I’ve forgotten the fix but I think it’s solved by
including winsock2.h from mingw. Have to check and experiment. I’m
hoping you or Tim are open to #ifdef’s or something similar :slight_smile:

I agree that a pre-made binary (linked against msvcrt.dll) for release
would be great.

I would like to get our new DevKit from RubyInstaller to be able to work
with your build.xml to compile everything by simply doing something like
“c:\devkit\devkitvars.bat” and ensuring “ant” and “%JAVA_HOME%\bin” are
on the PATH. Then Windows users can simply clone your repo, do the
super easy install of the DevKit, and not only build JRuby w/cext from
source, but also do things like “jruby -S gem install rdiscount
–platform=ruby” and have things just work. I think we’re close, let’s
see :slight_smile:

Roger P…looking for something else into for a bit? :wink:

Jon


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On 13 August 2010 11:27, Jon [email protected] wrote:

This is the known missing sys/select.h issue on mingw. It’s been such a long time that I’ve forgotten the fix but I think it’s solved by including winsock2.h from mingw. Have to check and experiment. I’m hoping you or Tim are open to #ifdef’s or something similar :slight_smile:

I’d just wrap that in #ifndef _WIN32 … #endif

It is most likely there because some extensions expect it to be
included by default. if not, then it should only be included by the C
file that needs it.


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

I’ve looked at how ruby core gets around the select() call but haven’t had time to find a Windows machine I can play on. I might have one ready tonight (in about 10h time), but if you get a patch ready (preferrably git format) I’ll apply it.

This from ruby core seems to address regular internet sockets

http://github.com/ruby/ruby/blob/trunk/include/ruby/win32.h#L239
http://github.com/ruby/ruby/blob/trunk/include/ruby/win32.h#L554

…but the following from cext makes me wonder if the select used by
cext’s threads use *nix domain sockets to communicate? If that’s true,
I’m fairly sure that simply #ifndef _WIN32 … replacing sys/select.h
with winsock2.h won’t fix things and I think you’d have to use something
like Windows named pipes instead.

http://github.com/jruby/jruby/blob/cext/cext/src/thread.cpp#L19
http://github.com/jruby/jruby/blob/cext/cext/src/thread.cpp#L67

That said, I’m not familiar with how cext’s threads behave and
unfortunately I’ve run out of time today to look into it more…not
going to be able to get you a patch for testing tonight :frowning:

Jon


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

I’ve looked at how ruby core gets around the select() call but haven’t
had time to find a Windows machine I can play on. I might have one ready
tonight (in about 10h time), but if you get a patch ready (preferrably
git format) I’ll apply it.

On Aug 13, 2010, at 3:27 AM, Jon wrote:

too).

Jon


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Hi

On Aug 13, 2010, at 4:49 PM, Jon wrote:

This from ruby core seems to address regular internet sockets

http://github.com/ruby/ruby/blob/trunk/include/ruby/win32.h#L239
http://github.com/ruby/ruby/blob/trunk/include/ruby/win32.h#L554

I was talking more about this:

http://github.com/ruby/ruby/blob/trunk/thread.c#L2475
http://github.com/ruby/ruby/blob/trunk/thread.c#L2509

That said, I’m not familiar with how cext’s threads behave and unfortunately I’ve run out of time today to look into it more…not going to be able to get you a patch for testing tonight :frowning:

Well, I have installed your devkit on a windows machine (btw: is there
some proper terminal application for windows? The default cmd.exe is
quite difficult to work with, so to speak) and I have created a few
patches that, not very nicely, made everything at least compile on my
the windows machine. I’m still getting a linker error, I’ll look into
this if I can get a remote desktop connection to the windows PC in the
university network - working for the administrators in my first year was
a good way to get access to our gateways :wink:

-Tim


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Well, I have installed your devkit on a windows machine (btw: is there some proper terminal application for windows? The default cmd.exe is quite difficult to work with, so to speak) and I have created a few patches that, not very nicely, made everything at least compile on my the windows machine. I’m still getting a linker error, I’ll look into this if I can get a remote desktop connection to the windows PC in the university network - working for the administrators in my first year was a good way to get access to our gateways :wink:

That’s great news! I’ll do a pull.

Now that it compiled, I’m going to be very interested in running the
<DEVKIT_INSTALL>\dk.rb install script and see if things like “gem
install rdiscount --platform=ruby” allow the RDiscount native gem to be
compiled and used with JRuby.

re: cmd.exe replacement, you’ll likely creating a windows desktop
shortcut to <DEVKIT_INSTALL>\msys.bat which will give you a bash-like
shell experience in that you can use the cmds in <DEVKIT_INSTALL>\bin
like ls, cp, rm, grep, etc.

Initially the bash-like shell will look horrible but if you left click
on the upper left icon in the title bar and select “Properties”, you can
make things look better by tweaking the “Font” tab (use TrueType) and
the “Layout” tag (tweak the Screen Buffer sizes). You can also edit
<DEVKIT_INSTALL>\etc\profile (eg - call a ~/.bashrc) and add a
<DEVKIT_INSTALL>\home<USER>.bashrc.

Sounds like your time with the sysadmins was time well spent :slight_smile:

Jon

FYI - As soon as I get time to update our wiki [1] with usage info, I’m
going to release the updated DevKit with tweaks to the dk.rb install
script to make it more user friendly. Nothing else changed so you
should be fine using the version you have. However, if you want to use
the new version feel free to download it from [2] In lieu of proper
documentation for using the dk.rb installer helper script check out [3]
and the posts near the end.

[1] http://wiki.github.com/oneclick/rubyinstaller/development-kit
[2] http://rubyinstallerdev.heroku.com/downloads/
[3]
http://groups.google.com/group/rubyinstaller/browse_thread/thread/d9c226735a54679f


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Well, the select is basically what MRI does for unix systems. I have
only used this code for now as I didn’t have a Windows machine ready
(not even a VM, it has been a few years since I used Windows, well
before Vista and friends). They wrap their code in
#if defined(CYGWIN) || defined(_WIN32)
30 lines of windows code here
#else
select in a blocking region
#endif
and I haven’t had time to understand the threading code completely, yet
(it’s one of the last things that is not passing the capi specs, I’m
down to 8 failures, 2 errors).
I’ve found a Windows machine at Uni now, which I can use, so I’ll look
into that in the next few hours.

-Tim

On Aug 13, 2010, at 4:49 PM, Jon wrote:

http://github.com/jruby/jruby/blob/cext/cext/src/thread.cpp#L67


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

This is a Windows 7 machine. I’ve gotten the library to compile, but it
doesn’t want to compile the extensions - undefined references.
I’m using the following commands and output:

cc -IC:/Users/tim.felgentreff/Desktop/devkit/rubyspec/optional/capi/ext -IC:/Users/tim.felgentreff/Desktop/devkit/jruby/lib/native/include/ruby -fno-omit-frame-pointer -fno-strict-aliasing -fexceptions -fPIC -c C:/Users/tim.felgentreff/Desktop/devkit/rubyspec/optional/capi/ext/array_spec.c -o C:/Users/tim.felgentreff/Desktop/devkit/rubyspec/optional/capi/ext/array_spec.o"

C:/Users/tim.felgentreff/Desktop/devkit/rubyspec/optional/capi/ext/array_spec.c:1:0:
warning: -fPIC ignored for target (all code is position independent)

cc -shared C:/Users/tim.felgentreff/Desktop/devkit/rubyspec/optional/capi/ext/array_spec.o -LC:/Users/tim.felgentreff/Desktop/devkit/rubyspec/optional/capi/ext -o C:/Users/tim.felgentreff/Desktop/devkit/rubyspec/optional/capi/ext/array_spec.dll"

C:/Users/tim.felgentreff/Desktop/devkit/rubyspec/optional/capi/ext/array_spec.o:
array_spec.c:(.text+0x1e): undefined reference to `rb_num2long’
… many more undefined references follow
collect2: ld returned 1 exit status

Under linux I’m using the same compile and link flags, so I’m not sure
what’s wrong here. I vaguely remember that “-shared” didn’t work under
mingw as it did with linux. I remember that I had to compile e.g. E17
completely statically under Windows. Cannot remember why, though. Any
thoughts?

Oh, and could you add a “cc” link to gcc in your devkit?

-Tim

On Aug 13, 2010, at 11:16 PM, Jon wrote:

191: ruby 1.9.1p429 (2010-07-02 revision 28523) [i386-mingw32]
192: ruby 1.9.2dev (2010-08-09 revision 28936) [i386-mingw32]
193: ruby 1.9.3dev (2010-08-13 trunk 28974) [i386-mingw32]


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

I forgot to mention a very useful tool for your newly found windows
machine…btw, which OS version?

It’s called ‘pik’ and it’s very similar to ‘rvm’ on *nix
http://github.com/vertiginous/pik

I use it all the time to test things out between different Ruby
implementations…

[C:\Users\Jon\Documents\RubyDev]pik ls
110: IronRuby 1.1.0.0 on .NET 4.0.30319.1

  • 151: jruby 1.5.1 (ruby 1.8.7 patchlevel 249) (2010-06-06 f3a3480)
    (Java H…
    187: ruby 1.8.7 (2010-06-23 patchlevel 299) [i386-mingw32]
    191: ruby 1.9.1p429 (2010-07-02 revision 28523) [i386-mingw32]
    192: ruby 1.9.2dev (2010-08-09 revision 28936) [i386-mingw32]
    193: ruby 1.9.3dev (2010-08-13 trunk 28974) [i386-mingw32]

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

This is a Windows 7 machine. I’ve gotten the library to compile, but it doesn’t want to compile the extensions - undefined references.

Unfortunately I couldn’t get it compile on my Win7 Ultimate 32-bit
machine. The attached patch allows me to build and part of the problem
was the build.xml patch I sent you caused the new make.bat to fail
because it didn’t handle “make CC=gcc” correctly. I’m not sure all the
mods I made to Makefile are needed, but we can tune later. Does this
patch work for you when running “ant clean cext”?

Oh, and could you add a “cc” link to gcc in your devkit?

I’ve added the following to my C:\DevKit\mingw\bin\cc.bat file
@ECHO OFF
gcc.exe %*

I think this is fine and needs to go into the release version of the new
DevKit, but I want a couple of the other RubyInstaller contributors to
double check. Good catch, thanks.

Even with all of the above, I’m still not able to install the native
rdiscount gem and it looks like there’s some mkmf.rb work still left to
do. The good news is that the gem pre_install hook seems to be working
fine on JRuby like we’ve seen on other impl’s…making progress :slight_smile:

C:\Users\Jon\Documents\CDev\rdiscount>jruby -S gem install
rdiscount-1.6.5.jm1.gem
JRuby limited openssl loaded. http://jruby.org/openssl gem install
jruby-openssl for full support.
Temporarily enhancing PATH to include DevKit…
Building native extensions. This could take a while…
ERROR: Error installing rdiscount-1.6.5.jm1.gem:
ERROR: Failed to build gem native extension.

C:/Users/Jon/Documents/JavaDev/jruby/bin/jruby.exe extconf.rb
WARNING: JRuby does not support native extensions or the mkmf' library very well. Check http://kenai.com/projects/jruby/pages/Home for alternatives. C:/Users/Jon/Documents/JavaDev/jruby/lib/ruby/1.8/mkmf.rb:31 warning: already initialized constant RUBY_PLATFORM checking for random()... no checking for srandom()... no checking for rand()... make make: *** No rule to make targetruby.h’, needed by `basename.o’.
Stop.

Jon

Hi

On Aug 14, 2010, at 4:54 AM, Jon wrote:

This is a Windows 7 machine. I’ve gotten the library to compile, but it doesn’t want to compile the extensions - undefined references.

Unfortunately I couldn’t get it compile on my Win7 Ultimate 32-bit machine. The attached patch allows me to build and part of the problem was the build.xml patch I sent you caused the new make.bat to fail because it didn’t handle “make CC=gcc” correctly. I’m not sure all the mods I made to Makefile are needed, but we can tune later. Does this patch work for you when running “ant clean cext”?

I don’t use the “ant cext” target because I couldn’t get both javac and
devkit to run in the same shell on windows, so I’m doing ant jar in one
shell and a direct make in the cext/src in another.

I tried it with deactivating the dependency of cext on the jar, and that
built the cext code fine, so yes, it kinda works.

Even with all of the above, I’m still not able to install the native rdiscount gem and it looks like there’s some mkmf.rb work still left to do. The good news is that the gem pre_install hook seems to be working fine on JRuby like we’ve seen on other impl’s…making progress :slight_smile:

The generated Makefile is not really different from the one MRI
generates, save for the include paths, and the same as on unix.
I checked the include flags, they look fine, for some reason the
dependency on ruby.h and defines.h is not checked against those paths on
windows. Ah well, I removed the dependencies, we don’t really need them,
anyway, I just wanted to keep the diff against MRI’s mkmf small.

C:\Users\Jon\Documents\CDev\rdiscount>jruby -S gem install rdiscount-1.6.5.jm1.gem

Doing a “jruby -S gem install rdiscount” now gives me the same linker
error as the capi specs.

C:\Users\tim.felgentreff\Desktop\devkit\jruby\cext\src>jruby -S gem
install rdiscount
JRuby limited openssl loaded. http://jruby.org/openssl
gem install jruby-openssl for full support.
Temporarily enhancing PATH to include DevKit…
Building native extensions. This could take a while…
ERROR: Error installing rdiscount:
ERROR: Failed to build gem native extension.

C:/Users/tim.felgentreff/Desktop/devkit/jruby/bin/jruby.exe extconf.rb
WARNING: JRuby does not support native extensions or the mkmf' library very well. Check http://kenai.com/projects/jruby/pages/Home for alternatives. C:/Users/tim.felgentreff/Desktop/devkit/jruby/lib/ruby/1.8/mkmf.rb:31 warning: already initialized constant RUBY_PLATFORM checking for random()... no checking for srandom()... no checking for rand()... make cc -I. -I. -IC:/Users/tim.felgentreff/Desktop/devkit/jruby/lib/native/include/ruby -I. -DHAVE_RAND -DHAVE_SRAND -fno-omit-frame-pointer -fno-strict-aliasing -fexceptions -m32 -c basename.c cc -I. -I. -IC:/Users/tim.felgentreff/Desktop/devkit/jruby/lib/native/include/ruby -I. -DHAVE_RAND -DHAVE_SRAND -fno-omit-frame-pointer -fno-strict-aliasing -fexceptions -m32 -c Csio.c ..... more compilation cc -shared -o rdiscount.dll basename.o Csio.o css.o docheader.o dumptree.o emmatch.o generate.o html5.o markdown.o mkdio.o rdiscount.o resource.o tags.o toc.o xml.o -L"." -L"/Users/tim.felgentreff/Desktop/devkit/jruby/lib" -m32 rdiscount.o:rdiscount.c:(.text+0x28): undefined reference torb_intern2’
rdiscount.o:rdiscount.c:(.text+0x49): undefined reference to
rb_funcall' rdiscount.o:rdiscount.c:(.text+0x58): undefined reference torb_str_buf_new’
… more undefined references

So the question is, what do I need to tell mingw’s gcc to link those
undefined references dynamically?

-Tim


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On 14 August 2010 20:36, Tim F. [email protected] wrote:

cc -shared -o rdiscount.dll basename.o Csio.o css.o docheader.o dumptree.o emmatch.o generate.o html5.o markdown.o mkdio.o rdiscount.o resource.o tags.o toc.o xml.o -L"." -L"/Users/tim.felgentreff/Desktop/devkit/jruby/lib" -m32
rdiscount.o:rdiscount.c:(.text+0x28): undefined reference to rb_intern2' rdiscount.o:rdiscount.c:(.text+0x49): undefined reference torb_funcall’
rdiscount.o:rdiscount.c:(.text+0x58): undefined reference to `rb_str_buf_new’
… more undefined references

So the question is, what do I need to tell mingw’s gcc to link those undefined references dynamically?

jruby-cext.dll should work, assuming it will be found at load time.
We could (maybe should?) do this for unixen as well … again,
assuming it is in an appropriate place to be located at runtime.


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Hi

jruby-cext.dll should work, assuming it will be found at load time.

I can’t tell it to just -ljruby-cext, complains that it cannot find it
(even though it is in -L path).

We could (maybe should?) do this for unixen as well … again,
assuming it is in an appropriate place to be located at runtime.

Well, the logic is currently that the jruby-cext library, if it is
within the Jar and thus cannot be loaded by the system directly, is
extracted to java.io.tmpdir, which can be set via VM parameter and is
something in /tmp per default. That’s what QtJambi does. Is that
inappropriate?

-Tim

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Before I head out of town for the weekend, a few quick thoughts…

Unfortunately I couldn’t get it compile on my Win7 Ultimate 32-bit machine. The attached patch allows me to build and part of the problem was the build.xml patch I sent you caused the new make.bat to fail because it didn’t handle “make CC=gcc” correctly. I’m not sure all the mods I made to Makefile are needed, but we can tune later. Does this patch work for you when running “ant clean cext”?

I don’t use the “ant cext” target because I couldn’t get both javac and devkit to run in the same shell on windows, so I’m doing ant jar in one shell and a direct make in the cext/src in another.

That’s ugly and unusable. I’ll add a <DEVKIT_HOME>\devkitvars.sh file
similiar to purpose of the devkitvars.bat file. The DevKit must be
able to be used from either a clean cmd.exe shell or an
MSYS-bash-using-cmd shell.

rdiscount.o:rdiscount.c:(.text+0x28): undefined reference to rb_intern2' rdiscount.o:rdiscount.c:(.text+0x49): undefined reference torb_funcall’
rdiscount.o:rdiscount.c:(.text+0x58): undefined reference to `rb_str_buf_new’
… more undefined references

So the question is, what do I need to tell mingw’s gcc to link those undefined references dynamically?

Looks like library load path issues not being able to find the import
library or the dll. Where do these symbols live, a ruby core or cext
dll/so?

One of the cool things with mingw is that you can link directly with the
dll and not just the import library. No time right now to test, but
check out http://sourceware.org/binutils/docs/ld/WIN32.html#WIN32 which
may have some info to help.

FYI, when building libs to run with MRI we need to link everything
against msvcrt.dll and ensure the correct msvcrt-rubyXYZ.dll to prevent
segfaults, i.e. - extensions running on MRI 1.8 must link against the
ruby 1.8 and 1.9 against the ruby 1.9. Don’t know if these are issues
with cext, but I definitely think the
link-against-msvcrt-for-all-built-extensions is the same.

Regarding the CC issue, adding an cc.bat and cc.sh is going to cause us
issues for the RubyInstaller project. Instead I’m going to update the
operating_system.rb file so that the pre_install hook set’s this up
correctly. That in combination with the mods to build.xml should fix
everything without having to resort to cc.bat/cc.sh stubs…can always
do make CC=gcc when the running from the command line. Do you see any
issues with this approach?

Great stuff, good luck, and I’ll be back online Monday latest.

Jon


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

jruby-cext.dll should work, assuming it will be found at load time.

I can’t tell it to just -ljruby-cext, complains that it cannot find it (even though it is in -L path).

I can’t duplicate this. Editing rdiscount’s Makefile to the following,
jruby-cext.dll was found

ldflags =
-LC:/Users/Jon/Documents/JavaDev/jruby/lib/native/i386-Windows
-ljruby-cext

Except for “jruby_str_length” and “jruby_str_cstr” all the other
undefinded reference errors for rdiscount.o went away when I forced
linkage against both c:\ruby187\bin\msvcrt-ruby18.dll and
c:\ruby191\bin\msvcrt-ruby191.dll I’m sure this isn’t how cext is
supposed to work, but it tells me we’re missing a link against the
equivalent JRuby artifact exporting all those symbols. Using -lffi-1.0
and -ljruby (in <JRUBY_ROOT>/bin) didn’t do it for me and I’ve not found
the right artifact yet.

To confirm, JRuby doesn’t have an rbconfig.rb file but generates the
RbConfig::CONFIG hash from src/org/jruby/libraries/RbConfigLibrary.java
and whatever mods we end up with will likely require changes there and
cext/src/Makefile?

Jon


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

went away when I forced linkage against both c:\ruby187\bin\msvcrt-ruby18.dll and c:\ruby191\bin\msvcrt-ruby191.dll I’m sure this isn’t how cext is supposed to work, but it tells me we’re missing a link against the

Linking against anything from MRI is really, really bad. jruby-cext
provides the jruby implemention of those symbols, and mixing the two
will make jruby asplode.

Yikes, probably just as fun as mixing MRI 1.8 extensions with 1.9 MRI
core. My point was that the link worked better (obviously) when the
extension found the symbols it wanted. Too bad it came across as
suggesting link-cext-against-MRI-artifacts as the way to go.

The symbols might not be exported correctly
for windows, when jruby-cext.dll is built, it probably needs an
additional linker flag to export all symbols.

Agreed. Using the graphical http://www.dependencywalker.com/ shows
jruby-cext.dll only exporting symbols (ordinals 1-40) like “JNI_OnLoad”
and “Java_org_jruby_cext_Native_newRString” and
“Java_org_jruby_cext_Native_getTrue” but none of the jruby
implementations of the MRI symbols.

According to http://sourceware.org/binutils/docs/ld/WIN32.html#WIN32 the
–export-all-symbols is ld’s default except if you (a) provide a DEF, or
(b) any symbol in jruby-cext marked with __declspec(dllexport)
attribute. Haven’t double checked…currently only have time to give to
cleaning up the DevKi to work with JRuby before officially releasing it.
Need to drop something else as jruby-cext is a great idea.

From what you’ve seen so far do you agree that RbConfigLibrary.java will
likely need to be updated as well as cext’s Makefile?


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs