shared version of libtcc.a (libtcc.so) about alien-tinycc HOT 4 OPEN

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.

from alien-tinycc.

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 .dll. The above commands work on Linux and I was able to use them to generate a library that I could use with FFI::Raw to build and run Tiny C code from Perl. I just include them to hopefully get the ball rolling, each platform will likely have its own idiosyncrasies and incantations.

There are some discussions about the static / dynamic issue for Alien::Base here:

Perl5-Alien/Alien-Base#11

And this is how we addressed it:

Perl5-Alien/Alien-Base#51

summary is:

If at all possible, it is best not to use a dynamic library from an Alien's share directory (example: Alien::Foo) for a XS module (example: Foo::XS). For one thing, the library search path needs to be updated at run time in order to find the dynamic library. Historically, Alien::Base did this by updating the paths in DynaLoader when you use Alien::Foo, although this doesn't work everywhere (notably Windows or Solaris, but probably other places). This also meant that Alien::Foo becomes a run time as well as build time dependency for any Foo::XS. The other issue is that upgrades to Alien::Foo can break Foo::XS. Using a static library to build Foo::XS fixes both of these issues.

from alien-tinycc.

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 build-tcc.bat.

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 build-tcc.bat so that it builds both a static and a shared library for Windows, and then we just need to take a little bit of care with how we copy the dll. Heck, it may be possible to include the static library build commands by hand. As for the install stage on Unixen, it may be possible to install the static library as it already does, then (1) rerun configure with --disable-static, (2) run make, and (3) copy only the shared library to the desired location, omitting the rest of the headers. I wonder if tcc would then have trouble knowing where to find its libraries.

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.

from alien-tinycc.

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.

from alien-tinycc.