Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error: incompatible pointer to integer conversion in latest clang #6

Open
d4rky-pl opened this issue Jul 9, 2024 · 10 comments
Open

Comments

@d4rky-pl
Copy link

d4rky-pl commented Jul 9, 2024

When trying to build ruby-packer or a project with ruby-packer on latest MacOS with clang 15.0.0, it fails with the following errors:

/var/folders/4r/b6_yv6ys02q90xwd03zpwk240000gn/T/rubyc/ruby-3.1.3.dev/enclose_io_unix.c:643:35: error: incompatible pointer to integer conversion passing 'struct stat *' to parameter of type 'int' [-Wint-conversion]
                        access(mkdir_workdir_expanded, &buf)
                                                       ^~~~
/var/folders/4r/b6_yv6ys02q90xwd03zpwk240000gn/T/rubyc/ruby-3.1.3.dev/enclose_io_unix.c:650:35: error: incompatible pointer to integer conversion passing 'struct stat *' to parameter of type 'int' [-Wint-conversion]
                        access(mkdir_workdir_expanded, &buf)
                                                       ^~~~
@monfresh
Copy link

monfresh commented Sep 6, 2024

I am seeing this too starting with Apple's command line tools version 15.3. If I revert to CLT 15.1, I am able to compile my binaries with ruby-packer. I'd be happy to submit a PR, but I have no idea where to start. Any pointers would be appreciated.

I'd also love to learn how to add support for newer Ruby versions. Is it as simple as it was for replacing OpenSSL 1.1 with OpenSSL 3.x (i.e just downloading OpenSSL and plopping it in the vendor folder), or is there some patching of Ruby involved?

cc @ericbeland

@d4rky-pl
Copy link
Author

d4rky-pl commented Sep 6, 2024

@monfresh I'm not sure if this project is still alive but if you're looking for an alternative you should check out tebako, the maintainers there are very active and issues are tackled quite fast (it still has some rough edges though)

@ericbeland
Copy link
Owner

Hi, just to confirm, I decided to stop trying to support this for a couple reasons.

  • I had a business cases for it that went away
  • I'm not sure this is likely to be the long-term approach for packing things like this--between docker, wasm, and now tebako
  • There are extra edge-cases to this approach which can eat a lot of debugging time. For example, if you try and require something like the AWS ruby libraries in a command-line app, it can cause it to slow down quite a lot, because the file system. I had a command-line app and this was proving challenging.
  • I gave up while fighting with Windows.

@monfresh In terms of updating, I'm trying to remember. The process was roughly to just dump the files in and replace the libraries with the latest, and if they still compiled, keep them. When things failed I would look into what it was trying to run, try it at the command line, and google the heck out of whatever compile errors Now, i would probably use Bing (it is beating google for errors like this for me) and chatgpt.

It is quite possible that upgrades are easier now. The trick for later rubies, back then, was hacking some compiler flags, iirc.

@d4rky-pl
Copy link
Author

d4rky-pl commented Sep 6, 2024

@ericbeland considering this fork is still pretty high in Google, if you're no longer interested in maintaining it (which makes sense, packaging Ruby apps is a full time job 🥲) I think it would be nice if you updated README to point to alternatives and then archived the repo. At this point it's slowly rotting anyway since it doesn't work on latest macOS (and will likely stop working on Linux as well at some point)

@ericbeland
Copy link
Owner

@d4rky-pl I'm open to that--it made sense when I had a business case.

If anyone with a fork of ruby-packer wants into the list, or with an alternative, let me know! Please let me know of any other alternatives I should list as well.

@monfresh
Copy link

monfresh commented Sep 6, 2024

Thank you both for the details. Coincidentally, I had recently come across tebako, but if I'm understanding the README correctly, their "forward portable" philosophy is a huge limitation for me. It would mean that I would need to buy a separate Mac and install Monterey on it, and use it exclusively for building my CLI, in order for the resulting binaries to be executable on newer macOS versions.

With ruby-packer, I can build using my day-to-day Mac that's running on Sonoma, and the resulting binaries work just fine on older macOS versions. However, I won't be able to do this once I upgrade to Sequoia because it doesn't support CLT 15.1, unless I figure out a way to get ruby-packer to work with newer CLT.

An alternative option I'm considering is porting my CLI to Crystal.

@monfresh
Copy link

monfresh commented Sep 6, 2024

Good news! I downloaded Ruby 3.2.5 and put it in my local ruby-packer repo, and it worked with Xcode 15.4! Here's roughly what I did:

  • Download the Ruby 3.2.5 zip from the Ruby GitHub repo
  • Unzip it
  • Replace the contents of the ruby-packer ruby dir with the contents of the unzipped Ruby 3.2.5 dir
  • Add the required config.sub and config.guess files by running these commands from the ruby-packer repo:
cd ruby
ruby tool/downloader.rb -d tool -e gnu config.guess config.sub
./autogen.sh
  • Make sure to use Bison 3. Install it with Homebrew if necessary, then point to it while building:
PATH="$(brew --prefix bison)/bin:$PATH" bundle exec rake rubyc

The next step is to see if I can build my CLI with this new rubyc, and that it works as expected.

@monfresh
Copy link

monfresh commented Sep 6, 2024

Ha! I spoke too soon. It looks like the rubyc executable that got generated is ruby itself. When I run rubyc -v, it shows 3.2.5, and rubyc -h shows the help for the ruby command.

@ericbeland
Copy link
Owner

ericbeland commented Sep 6, 2024

I wish I had a better recollection of being in the weeds, but I think I may recall that I did something like diffing the actual Ruby source of the version, vs. the embedded ruby source vs. the original of the same version, and found there were changes to it around the enclose code. I think I then added those changes in to the new unzipped ruby, then recompiled.

@monfresh
Copy link

monfresh commented Sep 8, 2024

Success! I figured out the compilation error with the current repo. Looking more closely at the error, it was complaining that the access method on lines 643 and 650 of ruby/enclose_io_unix.c was being given a second argument of type struct stat instead of int that it was defined with. For some reason, this did not raise an error with older CLT, but starting with CLT/Xcode 15.3, this raises an error, as you would expect.

So then I noticed that the integer it's expecting is supposed to represent the mode, so then I did some research and found that you can get the mode from the buf struct via buf.st_mode. So, in the end, the fix was simple: replace &buf on lines 643 and 650 with buf.st_mode.

This fixed that error, but I also ran into some libffi errors, but in my case, I don't need libffi, and I don't need gdbm, ncurses, or readline either, so I commented out where they get stuffed in lib/compiler.rb, and now everything is working great.

I then tried the same thing with Ruby 3.2.5, making sure to keep all the ruby/squash* files that I had accidentally removed when I was first experimenting, and making sure to add all the hacks related to enclose_io back into the various Ruby files. This resulted in a successful generation of the rubyc binary, but when I compiled my CLI, it crashed related to not being able to load some files that come from the gems I use. So, I still have some work to do with Ruby 3.2.5, but I'm happy that I can still use ruby-packer with the latest CLT for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants