Feature #5873: Adopt FFI over DL

• Status: Closed
• Assignee: -
• Target version: -

[phasis68 (Heesob Park)]

Please adopt ffi internally in the place of dl.

I know there were many discussions about FFI and DL.
And the main problem is the libffi building issue on mswin32 and mswin64 compilers.

Now things have changed.
I forked Ruby FFI and made a modified for mswin32/64 compilers(https://github.com/phasis68/ffi)
I verified it works on Ruby 1.8.7,1.9.3 with mswin32/VC9,mswin32/VC10 and mswin64/VC10.

Regards,

Park Heesob

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Feedback

I don't get what you mean by "adopt internally".

I think DL also isn't used internally, and fiddle is used over DL.
Could you elaborate?

[phasis68 (Heesob Park)]

In order words, please replace exe/DL by libffi as Yui Naruse mentioned in

http://sourceware.org/ml/libffi-discuss/2010/msg00053.html

[nobu (Nobuyoshi Nakada)]

Do you mean bundling libffi itself wholly?
It doesn't sound like a nice idea, to me...

[phasis68 (Heesob Park)]

I suggest reimplementation of ext/DL using libffi just like Aaron Patterson did in https://github.com/tenderlove/ruby/commits/ffi.
And providing libffi as a separate library same as zlib or readline.

[luislavena (Luis Lavena)]

On Tue, Jan 10, 2012 at 9:39 AM, Heesob Park [e-mail] wrote:

I suggest reimplementation of ext/DL using libffi just like Aaron Patterson did in https://github.com/tenderlove/ruby/commits/ffi.
And providing libffi as a separate library same as zlib or readline.

Isn't that what Fiddle is about?

--
Luis Lavena
AREA 17

Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

[phasis68 (Heesob Park)]

What is the relation between DL and fiddle?
If they do the same thing, we can remove one.

On Tue, Jan 10, 2012 at 10:01:26PM +0900, Heesob Park wrote:

Issue #5873 has been updated by Heesob Park.

What is the relation between DL and fiddle?
If they do the same thing, we can remove one.

DL uses fiddle as a back end if fiddle is available. It used to be that
libffi wasn't supported on MSVC, so the original DL code is also
included.

I think libffi is now fully supported on MSVC, so we can remove the
original DL back end. Luis, or Nakamura USA, can either of you confirm
this is the case?

--
Aaron Patterson
http://tenderlovemaking.com/

[luislavena (Luis Lavena)]

libffi has bash wrapper script to compile with cl.exe

It should work, however was not part of mswin builds.

Sorry for top posting. Sent from mobile.
On Jan 13, 2012 8:50 PM, "Aaron Patterson" [e-mail] wrote:

On Tue, Jan 10, 2012 at 10:01:26PM +0900, Heesob Park wrote:

Issue #5873 has been updated by Heesob Park.

What is the relation between DL and fiddle?
If they do the same thing, we can remove one.

DL uses fiddle as a back end if fiddle is available. It used to be that
libffi wasn't supported on MSVC, so the original DL code is also
included.

I think libffi is now fully supported on MSVC, so we can remove the
original DL back end. Luis, or Nakamura USA, can either of you confirm
this is the case?

--
Aaron Patterson
http://tenderlovemaking.com/

[nobu (Nobuyoshi Nakada)]

Hi,

(12/01/14 8:48), Aaron Patterson wrote:

On Tue, Jan 10, 2012 at 10:01:26PM +0900, Heesob Park wrote:
I think libffi is now fully supported on MSVC, so we can remove the
original DL back end. Luis, or Nakamura USA, can either of you confirm
this is the case?

To remove original DL completely, we have to bundle libffi itself
wholly. As I've written already, it doesn't seem a good idea, to me.

--
Nobu Nakada

[kosaki (Motohiro KOSAKI)]

To remove original DL completely, we have to bundle libffi itself
wholly.

Why?

Example, openssl is really important and rubygems and some modules
strongly depend on it. but we don't bundle libopenssl itself. What's
different?

[kosaki (Motohiro KOSAKI)]

2012/1/15 Hiroshi Nakamura [e-mail]:

(2012/01/14 12:30), KOSAKI Motohiro wrote:

To remove original DL completely, we have to bundle libffi itself
wholly.

Why?

I have no idea about the original point and your question.

Example, openssl is really important and rubygems and some modules
strongly depend on it.

There are some features in several libraries that depends on ext/openssl
(ossl), but there's no library that depends on ossl for providing main
features of the library.  I don't think we can call this situation
'strongly depend on.'

digest ... not required but use ossl when it's available for security
securerandom ... ditto

drb/ssl ... requires ossl when you use ssl server
webrick/ssl ... ditto

net/http ... requires ossl when you connect to https
net/imap,pop,smtp ... requires ossl when you connect to a server via TLS

rubygems ... requires ossl when you connect source repo via https
            (sign feature uses ossl but the feature is not used)

Sorry for not providing thoughts to original topic this time.  I'm not
yet fully understand the point just from my laziness.

I meant, virtually, all people enabled ossl. but we don't get a lot of
confusion.
Maybe libffi is not so different.

On Sat, Jan 14, 2012 at 12:30:02PM +0900, KOSAKI Motohiro wrote:

To remove original DL completely, we have to bundle libffi itself
wholly.

Why?

Example, openssl is really important and rubygems and some modules
strongly depend on it. but we don't bundle libopenssl itself. What's
different?

Also, we don't bundle:

• zlib
• libyaml
• libdbm
• tk
• readline (or libedit)
• libcurses

I don't think we should bundle these, but rubygems depends on some of
them.

--
Aaron Patterson
http://tenderlovemaking.com/

[tenderlovemaking (Aaron Patterson)]

• Status changed from Feedback to Closed

DL uses fiddle (with ffi) as a backend if ffi is available, so I will close this. We can talk about embedding libraries in a different thread. :-)

(2012/01/14 12:30), KOSAKI Motohiro wrote:

To remove original DL completely, we have to bundle libffi itself
wholly.

Why?

I have no idea about the original point and your question.

Example, openssl is really important and rubygems and some modules
strongly depend on it.

There are some features in several libraries that depends on ext/openssl
(ossl), but there's no library that depends on ossl for providing main
features of the library. I don't think we can call this situation
'strongly depend on.'

digest ... not required but use ossl when it's available for security
securerandom ... ditto

drb/ssl ... requires ossl when you use ssl server
webrick/ssl ... ditto

net/http ... requires ossl when you connect to https
net/imap,pop,smtp ... requires ossl when you connect to a server via TLS

rubygems ... requires ossl when you connect source repo via https
(sign feature uses ossl but the feature is not used)

Sorry for not providing thoughts to original topic this time. I'm not
yet fully understand the point just from my laziness.

Best regards,
// NaHi