I am compiling a Lua script into a binary on MacOS Catalina.
luac -s -o bin/my-binary.luac src/my-code.lua"
However, the application consuming the compiled script runs a 32-bit version of Lua and can't read the bytecode of the 64-bit compiled Lua script. (Error message: bad header in precompiled chunk).
Can I somehow (cross)compile the Lua script on current MacOS to a 32-bit binary?
My alternative would be doing the compilation with Docker but maybe there is an even simpler approach.
I don't see any option for cross-compilation or changing the bitness, but you may be able to tweak the Lua code to produce the code you need. Here is the maillist thread for Lua 5.1 that recommends using #define LUAC_STR_SIZE_TYPE int.
If this doesn't work, you may be able to change ldump.c to produce 32-bit compatible code. The source code has the following comment (5.4): All high-level dumps go through dumpVector; you can change it to change the endianness of the result. You may be able to update it to change bitness by changing handling of DIBS, dumpSize, and several other places.
Related
I want my Windows C program compiled with GCC on MinGW64 toolchain to output inf, -inf etc. ANSI values instead of Windows specific one like 1.#IND.
So far I was adding the following line before including stdio.h to my header files to achieve it:
#define __USE_MINGW_ANSI_STDIO 1
That worked great and didn't cause any problems when using MSYS2 based distribution. That changed when I installed mingw64 build from winlibs (I need an older version of GCC than MSYS2 currently provides as GCC 12 introduced very significant performance regressions). The line gave me warnings about redefining macros. I've then found a post from one of the designers of MinGW system about it. Apparently that's an internal macro and shouldn't be used by the user. The suggested way is to define _MINGW_FEATURES so I tried:
__MINGW_FEATURES__ _MINGW_ANSI_STDIO
instead. While that worked for ANSI output it unfortunately resulted in the compiler not recognizing SCNu8 (or C99 standard %hhu) modifiers anymore.
What's the correct way to use GCC based on MinGW toolchain to both use ANSI STDIO output and allow C99 printf/scanf modifiers (like %hhu or at least SCNu8).
I am patching code into my car's ECU. This has a Motorola MC68376 processor, so I'm using the appropriate CPU32 instruction set.
I want to continue to write in assembly code so that I can explicitly manage control registers, RAM access and allocation, as well as copying code structures which are already in use.
My first patch was successfully compiled in EASy68k, but that program does not support the full instruction set for the CPU32. For example, the DIVS.L command is not supported, so I cannot take a quotient of a 32-bit value.
Thus, before writing my own compiler out of sheer incompetence with available tools, I'm looking for an easier path. I read that gcc has the capability to compile code for the CPU32, but I have failed to get it to work.
I'm using MinGW's gcc (6.3.0) and Eclipse (2020-03). I added the '-mcpu32' or '-march=cpu32' flags to the compiler call, according to:
https://gcc.gnu.org/onlinedocs/gcc/M680x0-Options.html
Unfortunately this returns an error:
gcc: error: unrecognized command line option '-mcpu32'; did you mean '-mcpu='?
or
error: bad value (cpu32) for -march= switch
May I please have some advice for making this work? Does anyone know of a better CPU32 compiler that works with Eclipse?
I did not understand that gcc is conventionally distributed as binary files that are compiled with different functionality to suit the needs of a given user.
There seem to be two paths forward:
1) compile my own cross-compiler version of GCC
2) download a pre-compiled cross-compiler version of GCC
I chose to follow route 2).
I began the process of installing the 'Windows Subsystem for Linux' and Ubuntu 20.04 Focal Fossa, because I found a pre-made compiler that should be capable of performing cross compilation for the m68k processor: "gobjc-10-m68k-linux-gnu"
https://ubuntu.pkgs.org/20.04/ubuntu-universe-i386/gobjc-10-m68k-linux-gnu_10-20200411-0ubuntu1cross1_i386.deb.html
While I was installing that, I also found an m68k-elf gcc toolchain that is pre-compiled for windows 10:
https://gnutoolchains.com/m68k-elf/
I played with the latter for much of today. Although I was unable to get the toolchain integrated well with Eclipse, it works from the command line to compile a *.s assembly code file. This includes compatibility with the '-mcpu32' flag that I wanted at the outset.
There is still a lot for me to figure out, even after floundering through learning gcc's assembler directives (https://www.eecs.umich.edu/courses/eecs373/readings/Assembler.pdf) and the differences in gcc's assembly syntax compared to the MC68k reference manual (https://www.nxp.com/files-static/archives/doc/ref_manual/M68000PRM.pdf).
I can even convert the code section of the output file to be a proper s-record by using objcopy with the '-O srec' and '--only-section=.text' flags. This helps me patch the code into my ECU.
Thus I've answered my original question.
I have a project written in gcc - bison -flex on Linux environment. All the project is implemented into a *.so file and is called from python-tkinter graphic surface.
There is a need to run it on windows. However I'd avoid to install all the windows equivalent of gcc - bison -flex programs.
Is it possible to force gcc IN LINUX ENVIRONMENT to compile WINDOWS DLL instead of *.so? It could make life easier to use the same technics as I do now: just do calls from python-tkinter graphic surface.
You can, of course, cross-compile it.
You'll need some packages installed, though.
Your normal project would be able to build if you use the MINGW equivalent of GCC for the target architecture.
Also, take a look at this:
Manual for cross-compiling a C++ application from Linux to Windows?
The linking can be kind of troublesome though, since it could come a time where softlinking fails due to versions. In that case you'll need to create some symbolic links to the correct version.
The output of the compilation process should be with -o DYNAMIC-LIBRARIE-NAME.dll and of course use the -shared flag.
Hope it gives you some pointers..
Regards.
I've downloaded MinGW with mingw-get-inst, and now I've noticed that it cannot compile for x64.
So is there any 32-bit binary version of the MinGW compiler that can both compile for 32-bit Windows and also for 64-bit Windows?
I don't want a 64-bit version that can generate 32-bit code, since I want the compiler to also run on 32-bit Windows, and I'm only looking for precompiled binaries here, not source files, since I've spent countless hours compiling GCC and failing, and I've given up for a while. :(
AFAIK mingw targets either 32 bit windows or 64 bit windows, but not both, so you would need two installs. And the latter is still considered beta.
For you what you want is either mingw-w64-bin_i686-mingw or mingw-w64-bin_i686-cygwin if you want to compile for windows 64. For win32, just use what you get with mingw-get-inst.
See http://sourceforge.net/apps/trac/mingw-w64/wiki/download%20filename%20structure for an explanation of file names.
I realize this is an old question. However it's linked to the many times the question has been repeated.
I have found, after lots of research that, by now, years later, both compilers are commonly installed by default when installing mingw from your repository (i.e. synaptic).
You can check and verify by running Linux's locate command:
$ locate -r "mingw32.*[cg]++$"
On my Ubuntu (13.10) install I have by default the following compilers to choose from... found by issuing the locate command.
/usr/bin/amd64-mingw32msvc-c++
/usr/bin/amd64-mingw32msvc-g++
/usr/bin/i586-mingw32msvc-c++
/usr/bin/i586-mingw32msvc-g++
/usr/bin/i686-w64-mingw32-c++
/usr/bin/i686-w64-mingw32-g++
/usr/bin/x86_64-w64-mingw32-c++
/usr/bin/x86_64-w64-mingw32-g++
Finally, the least you'd have to do on many systems is run:
$ sudo apt-get install gcc-mingw32
I hope the many links to this page can spare a lot of programmers some search time.
for you situation, you can download multilib (include lib32 and lib64) version for Mingw64:
Multilib Toolchains(Targetting Win32 and Win64)
By default it is compiled for 64bit.You can add -m32 flag to compile for 32bit program.
But sadly,no gdb provided,you ought to add it manually.
Because according to mingw-64's todo list, gcc multilib version is done,but gdb
multilib version is still in progress,you could use it maybe in the future.
Support of multilib build in configure and in gcc. Parts are already present in gcc's 4.5 version by using target triplet -w64-mingw32.
gdb -- Native support is present, but some features like multi-arch support (debugging 32-bit and 64-bit by one gdb) are still missing features.
mingw-64-todo-list
Using MacPorts i have just installed arm-elf-gcc on to my MacBook Pro. This worked flawlessly and all seems to run fine.
However, after compiling a simple hello world test program in C and C++ and trying to run either on the target board (an ARM9 based board running Debian Linux) they immediately seg fault.
I'm a bit stuck as how to go about debugging this, as the target board has limited tools available and no gdb. I have successfully built and run other code using a Linux hosted cross compiler so it should work.
Any ideas?
Following the suggestion I have built and run gdbserver, I get the following in gdb on the host:
Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
I thought it may be a problem with the standard c libs so I removed any calls and have just an empty main that return 0, it is compiled with -Wall -g hello-arm.cpp -static. As a test I compiled the same source with a Linux hosted cross compiler and it runs and exits fine. The only difference I can see is the that Linux compiled version is over twice the size and the difference in output from the file command:
arm-elf-gcc: ELF 32-bit LSB executable, ARM, version 1, statically linked, not stripped
arm-*-linux: ELF 32-bit LSB executable, ARM, version 1, statically linked, for GNU/Linux 2.4.18, not stripped
The usual method of debugging in this situation is to run gdbserver on the target board, and connect to it (via ethernet) with gdb running on a host computer.
Alternately, you could try comparing the assembly in a Mac-compiled "Hello World" program and a (working) Linux-compiled one to see what's different.
After digging around for a couple of days I am starting to understand a bit more about embedded compilers. I wasn't really sure of the difference between arm-elf-gcc installed via MacPorts and the arm-unknown-linux toolchain I had installed on my Linux box. I just came across a pdf titled "An introduction to the GNU compiler" which contains the following paragraph:
Important: Using the GNU Compiler to
create your executable is not quite
the same as using the GNU Linker,
arm-elf-ld, yourself. The reason is
that the GNU Compiler automatically
links a number of standard system
libraries into your executable. These
libraries allow your program to
interact with an operating system, to
use the standard C library functions,
to use certain language features and
operations (such as division), and so
on. If you wish to see exactly which
libraries are being linked into the
executable, you should pass the
verbose flag
-v to the compiler.
This has important implications for
embedded systems! Such systems do not
usually have an operating system.
This means that linking in the system
libraries is almost always
meaningless: if there is no operating
system, for example, then calling the
standard printf function does not make
much sense.
So when I get back to my dev machine later I will determine the libraries linked in with the Linux build and add them to the arm-elf-gcc build.
I'll update this when I have more information but I just want to document my findings in case any one else has these problems.