I'm writing a program in Nim using the zip/zipfiles library, which relies on libzip(|2|4).dylib.
My question is primarily for macOS, but guidance for Linux is also welcome.
How can I compile it to have a statically linked binary to be easier to distribute?
Thanks
Andrea
EDIT:
Apparently something like https://nim-lang.org/docs/nimc.html#dynliboverride should do.
Specifically for this library, -p:useLibzipSrc also does.
Reading through the source it seems like you may be able to do this by passing -d:useLibzipSrc
Related
We have been asked if our C++Builder VCL program could be compiled using gcc on linux. I don't believe this is in order to run the code, but to evaluate it using HP Fortify. I can't imagine how such a thing could be done, but most of you folks are smarter than me, perhaps someone can think of a way.
Thanks!
If I build a DLL with Rust language, does it require libgcc*.dll to be present on run time?
On one hand:
I've seen a post somewhere on the Internet, claiming that yes it does;
rustc.exe has libgcc_s_dw2-1.dll in its directory, and cargo.exe won't run without the dll when downloaded from the http://crates.io website;
On the other hand:
I've seen articles about building toy OS kernels in Rust, so they most certainly don't require libgcc dynamic library to be present.
So, I'm confused. What's the definite answer?
Rust provides two main toolchains for Windows: x86_64-pc-windows-gnu and x86_64-pc-windows-msvc.
The -gnu toolchain includes an msys environment and uses GCC's ld.exe to link object files. This toolchain requires libgcc*.dll to be present at runtime. The main advantage of this toolchain is that it allows you to link against other msys provided libraries which can make it easier to link with certain C\C++ libraries that are difficult to under the normal Windows environment.
The -msvc toolchain uses the standard, native Windows development tools (either a Windows SDK install or a Visual Studio install). This toolchain does not use libgcc*.dll at either compile or runtime. Since this toolchain uses the normal windows linker, you are free to link against any normal Windows native libraries.
If you need to target 32-bit Windows, i686- variants of both of these toolchains are available.
NOTE: below answer summarizes situation as of Sep'2014; I'm not aware if it's still current, or if things have changed to better or worse since then. But I strongly suspect things have changed, given that 2 years have already passed since then. It would be cool if somebody tried to ask steveklabnik about it again, then update below info, or write a new, fresher answer!
Quick & raw transcript of a Rust IRC chat with steveklabnik, who gave me a kind of answer:
Hi; I have a question: if I build a DLL with Rust, does it require libgcc*.dll to be present on run time? (on Windows)
I believe that if you use the standard library, then it does require it;
IIRC we depend on one symbol from it;
but I am unsure.
How can I avoid using the standard library, or those parts of it that do? (and/or do you know which symbol exactly?)
It involves #[no_std] at your crate root; I think the unsafe guide has more.
Running nm -D | grep gcc shows me __gc_personality_v0, and then there is this: What is __gxx_personality_v0 for?,
so it looks like our stack unwinding implementation depends on that.
I seem to recall I've seen some RFCs to the effect of splitting standard library, too; are there parts I can use without pulling libgcc in?
Yes, libcore doesn't require any of that.
You give up libstd.
Also, quoting parts of the unsafe guide:
The core library (libcore) has very few dependencies and is much more portable than the standard library (libstd) itself. Additionally, the core library has most of the necessary functionality for writing idiomatic and effective Rust code. (...)
Further libraries, such as liballoc, add functionality to libcore which make other platform-specific assumptions, but continue to be more portable than the standard library itself.
And fragment of the current docs for unwind module:
Currently Rust uses unwind runtime provided by libgcc.
(The transcript was edited slightly for readability. Still, I'll happily delete this answer if anyone provides something better formatted and more thorough!)
I am trying to figure out the easiest way to extract kernel data objects using static analysis tools, I found CIL as one option but looks like its more embedded in to GCC and may not be feasible when we need to run it with cross compiler. I wonder if any other C parser would help me for doing such task.
Could someone please recommend me a tool/utility to do static analysis of the kernel source code.
Did you try to explore the parser in clang. I have the same demand, some people refer me to clang. Haven't got time to get into it yet.
I was wondering if it's possible somehow to use windows.pas on OS X with Lazarus?
I need to use special library in my project, and one of key-files uses windows.pas :( Any ideas?
Windows.pas only works on Windows. You will have to edit the library to put an IFDEF around it in the uses clause, and then provide alternatives for any functionality that is then broken. Or contact the library author and see if there is already a non-Windows version available.
You certainly cannot use Windows.pas under OSX. Because Windows.pas exposes the functionality of the Win32 library.
If you need to execute Win32 code on OSX pretty much your only option is Wine.
A more plausible solution is that you find an alternative to this "special" library to which you refer.
Windows.pas is mostly a wrapper around different DLLs contained in the Windows operating system. As it is unlikely that you will find those DLLs in OSX I guess you are out of luck.
You could check the library's source code and try to identify the constants, procedures and functions that are used in windows.pas. If it is not too much code you could try to modify the library so that it uses corresponding Carbon functions instead.
While the various answers are correct, and the vast bulk of unit windows is not portable, some functionality IS abstracted. Structures like interlockedincrement, Rect and ColorRef, and some message related functionality. Have a look at types and lcltype and the system unit interface of FPC.
A lot of Delphi code still uses Windows for that functionality, while e.g. unit types already exists since D6.
Some other things are abstracted, but not using the same (windows unit) calls. Better explain what exactly you need in a separate post.
Is there an existing library to write code for the PIC32 in Ruby?
Currently I've been writing code in C to perform tasks on it, but I would love to use Ruby.
Thanks,
Andy
I doubt that there is an existing library for that task, but it should be possible (surely not without some effort) to extend Metasm to include a new assembler backend for your processor. It also includes a C parser/compiler.
EDIT: I just realized you are looking for a Ruby interpreter on that platform, which I hardly can believe exists.
I also doubt that Ruby on iron exists, but it would be nice to be wrong. :)
If your pic32 can handle an OS that would run Ruby, that might be an option. Otherwise you may be able to prototype a lot of your algorithms in locally run Ruby and then translate them to C on the PIC32.
Probably too late, but according to this link, mruby can run on pic32
As a consequence, the interpreter is now much reduced in size and can
be cross compiled for low cost 32-bit microcontrollers including ….
the PIC32 (MX7)! The official repository on GitHub contains already
examples for a few embedded platforms including the chipKIT MAX32!
https://github.com/mruby/mruby