Use rake-compiler-dev-box

[metaskills]

Closing issue #110 and move to rake-compiler-dev-box.

• Update to use iconv version v1.14.
• Set cross platform to 'x86-mingw32' and 'x64-mingw32'. Not sure what 'x86-mswin32-60' is?
• Removed my old notes.

[metaskills]

This is my current DIFF for rake-compiler-dev-box when compiling. This removes 1.8.7.
https://gist.github.com/metaskills/6395946

[metaskills]

@luislavena and/or @fbehrens

Here is my first attempt log with rake-compiler-dev-box. Maybe, I need to do some things with the virtual machines config.yml, some resources I was looking at below, but I need a small bit of guidance.

• https://github.com/libgit2/rugged/blob/development/Rakefile
• https://github.com/sparklemotion/sqlite3-ruby/blob/master/tasks/vendor_sqlite3.rake

[luislavena]

Hello @metaskills

I don't think there are things you need to change on the VM except remove 1.8.7, so that is good.

I noticed that the freetds dependency wasn't built prior the compilation, which might indicate a Rake task dependency issue.

Both rugged and sqlite3 examples might look convoluted (granted, they are) since they cover all the platforms required for the installation.

If you look closely to sqlite3, you will notice that we no longer set a cross_config_options to disable lookup but instead, inside vendor_sqlite3.rake we setup the path to the library we are linking against:

https://github.com/sparklemotion/sqlite3-ruby/blob/master/tasks/vendor_sqlite3.rake#L71-L73

platform in this context is obtained from the the array of cross-platforms you supplied and it is used to compile the recipe (sqlite3 in this case) for the target platform:

https://github.com/sparklemotion/sqlite3-ruby/blob/master/tasks/vendor_sqlite3.rake#L58-L68

By reading rbconfig.rb for the GCC host used.

This is necessary to be able to compile for i586-mingw32msvc compiler and x86_64-w64-mingw32 compiler. As you can see, I didn't mention i686-w64-mingw32 as platform, and that is simply because the code compiled with i586-mingw32msvc should be compatible to be linked with i686-w64-mingw32 but not the other way around.

I've discussed this in length starting here and also explained in my commit here

You will notice that then the compilation of the recipe is hook up to the cross task: https://github.com/sparklemotion/sqlite3-ruby/blob/master/tasks/vendor_sqlite3.rake#L75

Which triggers the compilation of all the sqlite3 recipes prior cross compiling the extension.

While far from ideal, it works 👅

Your recipe to compile both libiconv and freetds might require be changed to what I did in define_sqlite_task and feed the recipe.path into each platform specific configure options for both --with-iconv-dir and --with-freetds-dir.

Let me know if that helps a bit (most likely doesn't 😄)

[metaskills]

I read an obey :)

Truth be told, this stuff really just glosses my eyes with confusion. However, I will give it a shot. Remember, you too have push access to this repo/branch. So if you want to help just shout and I will watch. Otherwise, I'll give it a go.

[luislavena]

I'll send my commits later today.

Sorry for top posting. Sent from mobile.
On Aug 31, 2013 2:37 PM, "Ken Collins" notifications@github.com wrote:

I read an obey :)

Truth be told, this stuff really just glosses my eyes with confusion.
However, I will give it a shot. Remember, you too have push access to this
repo/branch. So if you want to help just shout and I will watch. Otherwise,
I'll give it a go.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/135#issuecomment-23610624
.

[luislavena]

Hello @metaskills

I just pushed the start of the modifications I'm planning to do to change how FreeTDS and libiconv are built and then how these are linked against the extension.

This of course breaks the extension compilation, but I'm focusing now in the dependencies.

Something I noticed in my environment (GCC 4.7.3) is that libsybdb fails to be generated:

/opt/local/bin/ranlib: file: .libs/libsybdb.a(gssapi.o) has no symbols
/opt/local/bin/ranlib: file: .libs/libsybdb.a(win_mutex.o) has no symbols
/opt/local/bin/ranlib: file: .libs/libsybdb.a(fakepoll.o) has no symbols
/opt/local/bin/ranlib: file: .libs/libsybdb.a(gettimeofday.o) has no symbols
/opt/local/bin/ranlib: file: .libs/libsybdb.a(lt1-iconv.o) has no symbols
libtool: link: ranlib .libs/libsybdb.a

Which results later on failure to link fisql:

libtool: link: gcc -D_THREAD_SAFE -fPIC -Wdeclaration-after-statement -o fisql fisql.o terminal.o edit.o handlers.o interrupt.o  ../../dblib/.libs/libsybdb.a ../../replacements/.libs/libreplacements.a /Users/luis/code/rails-sqlserver/tiny_tds/ports/x86_64-apple-darwin12.4.0/libiconv/1.14//lib/libiconv.a -lncurses -lreadline
ld: warning: ignoring file ../../dblib/.libs/libsybdb.a, file was built for archive which is not the architecture being linked (x86_64): ../../dblib/.libs/libsybdb.a
Undefined symbols for architecture x86_64:
  "_dbadata", referenced from:
      _main in fisql.o
  "_dbadlen", referenced from:
      _main in fisql.o
...
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[3]: *** [fisql] Error 1

I noticed this is caused by the usage of --disable-shared --enable-static used by MiniPortile against FreeTDS 0.91, so I'm assuming this is a problem with my environment (GCC 4.7.3) and not a general issue.

Will test against a Linux VM to confirm and will continue later tonight.

Can you test if the native compilation of ports:freetds works for you?

Thank you.

[metaskills]

Can you test if the native compilation of ports:freetds works for you?

Not it failed, details here. https://gist.github.com/metaskills/6401061
Really thankful for the help!

[luislavena]

Interesting that --with-libiconv-prefix causes that when it actually should have worked.

Problem I have is that playing with LDFLAGS and PATH do not work for the cross-compilation part...

Couldn't look on this during the weekend, will try it later today.

[matthew342]

@luislavena Any update? I'm not great at this stuff either, but happy to try to lend a hand.

[luislavena]

@matthew342 you can try checking out this branch and also looking at rake-compiler-dev-box, getting vagrant running and help out why FreeTDS is not linking with libiconv.

@metaskills I can't contribute right now, been for the past few weeks in the middle of a huge migration for a project and the upcoming two weeks don't look open neither.

What we need to investigate is the issue on FreeTDS not liking the libiconv also compiled for it. I think perhaps test with the native script might shed some light?

[dicom]

Is there any hope for this being resolved?

I'm still stuck on Ruby 1.9.3 for my work environment (Windows XP) because of this gem dependency, and would love to be able to upgrade to Ruby 2.0/2.1 as soon as possible (Ruby 1.9.3 is going EOL in april 2014 it seems).

[CodeInsider]

Ruby 1.9.2 will be supported until June 2014. This will give you some time.

But I'll hope too that this issue is going to be resolved for our windows users. This way we could migrate our whole software to Ruby 2.1.

[aharpervc]

Any update on this?

[wbond]

The issue is a conflict between an include directory that rake-compiler is setting when executing extconf.rb. For some reason include the current folder (.) as an include path (https://github.com/luislavena/rake-compiler/blob/master/lib/rake/extensiontask.rb#L162) breaks the detection of iconv, even when using explicit --with-iconv-include= config parameters.

I manually edited a local version of rake-compiler to get the cross-compile to happen. I did have to make a number of tweaks to the Rakefile to ensure that libiconv and freetds were seen as depedencies of the rake cross native gem command that rake-compile-dev-box is using inside of package_win32_fat_binary.

I'm going to work through trying to find a clean way to apply patches and so forth such that there should be a simple bash script or rake task to run and have the cross-compile happen.

I must say, while I have a great amount of respect for all of the work that went into making rake-compiler, mini_portile, rake-compiler-dev-box and all of the rake tasks in tiny_tds, the current compile stack is extremely indirect and very hard to debug. I would love to try and propose a simpler solution at some point. That said, I know that the current choices were made to solve real problems, so I'd want to be confident that I was helping the situation, not just rewriting it into a different kind of complexity.

[wbond]

Turns out I was completely wrong. The include issue I saw was related to not properly setting the host when building the dependencies. Apparently removing the include for . was actually causing the whole compile environment to fall back to a non-cross-compile.

Anyway, the result is good news because I figured out all of the appropriate fixes and added some rake tasks to make the cross-compilation simple. See #161 for results.

[wbond]

This has been superseded by #161