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
shared version of libtcc.a (libtcc.so) #6
Comments
Hey plicease, Thanks for the suggestion and potential solution. I assume this solution works on systems that use .so files, i.e. linux and maybe flavors of BSD. As for the static vs shared issues, I have little knowledge and no strong preference. Is there an Alien::Base discussion where I can read more about this? FWIW, this Alien module is minimal. It simply executes tcc's own build scripts, after applying patches where necessary to get the thing to build. Ideally, this static vs shared library setting would be something to push back upstream. So I'd love to incorporate your idea, but I'm afraid I might need a little bit of hand holding to get it done. |
Agreed upstream would be the best place to provide support. Maybe you can point me in the appropriate place? I noticed btw- that the Windows build seems to generate a There are some discussions about the static / dynamic issue for Alien::Base here: And this is how we addressed it: summary is: If at all possible, it is best not to use a dynamic library from an Alien's share directory (example: |
Coming back to this finally. It should be noted that Alien::TinyCC works as expected on all systems, so this is an enhancement request. We have two issues. (1) Should Alien::TinyCC build static libraries across all operating systems, and (2) should Alien::TinyCC provide shared libraries in addition to the static ones? Based on the discussion that you link to, I like the idea of switching to a static library on Windows. This is easy for the Alien package to achieve independent of upstream by patching As for providing a shared library across systems, I am for this if it is easy to achieve with minimal patching. For example, it may be possible to patch I'm not strongly motivated to make these changes, since everything works at the moment, but I'll be happy to look over and try any pull requests that you send my way. I'll keep this open for now. |
Understood. I always considered this a feature request. I am using this module from FFI::TinyCC, but it is working fine atm as is. Ideally this would be handled by tinycc itself, but the important thing is that it works. |
I think it would be interesting to do some FFI / tcc integration (see
FFI::Raw
), unfortunately thelibtcc
that this Alien module generates is static only. I was able to get a dynamic version of the library thus:and then use libtcc.so from a
FFI::Raw
script.My experience with
Alien::Base
has shown that you don't want to use alien built dynamic libraries when creating .so files for XS modules, so perhaps the libtcc.so could be installed in a separatedynamic
directory, so that it could be used by FFI but ignored by XS (this is what we do inAlien::Base
when thealien_isolate_dynamic
option is used).The text was updated successfully, but these errors were encountered: