How to compile Haxe code using cpp target that is fully stripped, no debug addons etc?
What can be used except -D dce=full and --no-traces to compile fastest and/or smallest executable?
-D dce=full and --no-traces and avoiding -debug should make the build ready to deploy, on all Haxe targets.
Also good to know; In Haxe 3.2 the static analyzer is introduced, which was hidden under a compiler flag (-D analyzer). The static analyzer takes care of const propagation, copy propagation, local dead code elimination, fusion and purity inference.
In Haxe 3.4 the static analyzer has settled and runs by default, so the -D analyzer flag has been removed. But to have extra optimizations the -D analyzer-optimize can be used. This builds a control flow graph and then the optimizer (if enabled) does some optimizations on that, like folding expressions, removing dead code, etc. This optimization flag is not enabled by default because of too many vars being eliminated for hxcpp, in Haxe 4.0 it will be enabled by default.
So I don't know which Haxe version you use, but you might want to check out if this analyzer helps for your build. It probably also depends on which (if any) framework you are using.
Related
I have blindly followed this tutorial for installing PostgreSQL and Apache AGE and would like to understand more about the process better. In the video, he has used a lot of options and flags for the ./configure command which I have copied below:
./configure --prefix=$(pwd) --enable-cassert --enable-debug CFLAGS="-glldb -ggdb -0g -g3 -fno-omit-frame-pointer"
He has mentioned --prefix=$(pwd) is required for setting a custom location as he has multiple of Postgres instances intalled. Does this mean without doing this, Postgres will be installed to the same location every time? If so, where will it be installed? I am unable to find it in any of my system files, unlike when I have installed Postgres using the packages and installers, which showed up in my /libraries directory.
--enable-cassert and --enable-debug are used to enable dev tools for debugging but it is not clear to me the differences between them.
As for the CFLAGS, I have no idea what is going on.
Thank you in advance.
Most of the answers to your questions can be found on the official documentation for Postgres. I've linked it below, but I'll also focus on the points you mentioned.
https://www.postgresql.org/docs/current/install-procedure.html#CONFIGURE-OPTIONS
--prefix=$(pwd) --enable-cassert --enable-debug
All the above are configuration parameters that postgres itself uses. Taken directly from the documentation, here is what they mean:
--prefix=PREFIX
Install all files under the directory PREFIX instead of /usr/local/pgsql. The actual files will be installed into various subdirectories; no files will ever be installed directly into the PREFIX directory.
--enable-debug
Compiles all programs and libraries with debugging symbols. This means that you can run the programs in a debugger to analyze problems. This enlarges the size of the installed executables considerably, and on non-GCC compilers it usually also disables compiler optimization, causing slowdowns. However, having the symbols available is extremely helpful for dealing with any problems that might arise. Currently, this option is recommended for production installations only if you use GCC. But you should always have it on if you are doing development work or running a beta version.
--enable-cassert
Enables assertion checks in the server, which test for many “cannot happen” conditions. This is invaluable for code development purposes, but the tests can slow down the server significantly. Also, having the tests turned on won't necessarily enhance the stability of your server! The assertion checks are not categorized for severity, and so what might be a relatively harmless bug will still lead to server restarts if it triggers an assertion failure. This option is not recommended for production use, but you should have it on for development work or when running a beta version.
CFLAGS="-glldb -ggdb -0g -g3 -fno-omit-frame-pointer"
As for the above, these are options you can set for the C compiler itself, not postgres. You can look them up individually for more info, but to give you an idea, -0g is a compiler flag that decides the level of code optimization performed by the compiler. Here's a link containing more info:
https://wiki.gentoo.org/wiki/GCC_optimization/en#-O
I have written a plugin for vanilla lua. I wish to protect this plugin, and I have heard of obfuscation. I tried XFuscator, but even after fixing line 5's logic, it doesnt work. Are there any newer, better ones floating out there?
Thanks!
If you are going to run your Lua script in the same machine you build it (I mean, same Lua version, same machine architecture), you could just compile it to bytecode using luac like this:
luac -s -o example.out example.lua
And distribute the .out file, that doesn't contain the Lua source code.
Note that Lua bytecode is platform specific (endianness, word size), and it could change in future Lua versions (in fact it already did in the past). For that reason, if you compile it, let's say, in a Intel x86-64 with Lua 5.3, you should run your generated .out only in this kind of machines or compatible ones.
I'm using a couple of macros from the autoconf archive in my configure.ac. When aclocal is run, the macros are placed in aclocal.m4. Since this file is automatically generated, I typically wouldn't put it in source control. However, the autogeneration won't work unless the user has the macros installed on their computer in the first place (on Ubuntu I had to do apt-get install autoconf-archive). Is it typical practice to include aclocal.m4 in source control?
Edit: summary: Do not include aclocal.m4 in source control. It is acceptable to include acinclude.m4.
No, it is not best practice to do so. However, it is probably typical practice. Best practice and common practice often diverge widely when dealing with the autotools. In my opinion, the expectation is that a developer who is running the autotools is capable of satisfying the dependencies and making the macros available (eg, by installing autoconf-archive), so the file should not be included in the version control system. It is, however, perfectly acceptable to put the macros in acinclude.m4 and put that file in source control. When invoked, aclocal will look for definitions in acinclude.m4 so that the developer running aclocal (and this is the point that seems to throw a lot of projects; there are really only a small handful of people who should ever be invoking the autotools on a project, and everyone else should be building from a release distribution. If developers working on a project are not modifying the autotool meta-files, there is no reason for them to be running the autotools) does not need to install the autoconf archive.
I created a C++ shared library project in Ubuntu with compiler g++ 4.6.
Some of the dependency libraries expects some preprocessor commands about compiler and operating system to properly compile, like
#elif defined(__GNUC__) || defined(__llvm__) || defined(__clang__)
However Eclipse doesn't define them automatically (at least the version I'm using), is there a setting or option in Eclipse which does this for me ?
You can set preprocessor defines in the project properties: .
However, in your case, I wouldn't use these, as they shouldn't be project specific (due to them being compiler specific). I actually think you're looking for these. I'm not sure for llvm/clang (there are ones, but I don't remember them right now), but for GCC you should use the macro __GNUC__ which will be defined by the compiler itself, without you having to worry about it. The leading underscores tell you, that they aren't part of the standard and not necessarily defined when using another compiler (e.g. MSVC).
For cross platform usage of vsprintf_s:
// this will be set on Visual Studio only, so this code is added for all other compilers
#ifndef _MSC_VER
#define vsprintf_s(b,l,f,v) vsprintf(b,f,v);
#endif
But in general, try to use functions that are available on all platforms (for this example, in this case use vsnprintf() instead).
I'm trying to cross-compile several libraries from OSX to iOS. I've successfully cross-compiled libjpeg and libogg.
But I can't compile libvorbis because configure insists on creating and running a small test program. This obviously fails, because it creates an armv7 binary, fails to run it, and then interprets this as missing ogg libraries.
How do you usually deal with this kind of problem? I'm tempted to hack the configure script to work around these issues, but because of this kind of failure some features may be disabled. I'm also thinking of letting configure generate a native Makefile and then convert it to use the iOS toolchain, but this seems too error prone.
Any advice?
If you are cross-compiling anything that has more dependencies than libc (glibc) it becomes much more complicated. You need to have already cross-compiled all the dependencies. And the cross-compiler toolchain and all helper build programs and scripts need to know how to find those dependencies (the cross-compiled libraries and headers).
You need to have already cross-compiled libogg (and its dependencies) and installed them into the cross-compile root directory. The headers and libraries from your build system can't be used for the host (arm7) system. They must be kept separate.
Also, if you want to have shared object libraries (*.so) and not just static libraries then there is a whole new set of complications. For example, while a cross-compiler toolchain contains a cross-compiled libc as part of the toolchain, you still need a libc for the host system. The libc that is part of the toolchain can be used for this, but the way it is structured is different than on the host system. Sometimes people copy and re-arrange the files, but often people just compile and install a new glibc for the root.
Anyways, all that to say, the two errors you are seeing are because the configure script is not able to find a cross-compiled libogg library. If you haven't already, you need to cross-compile libogg (and dependencies) and install them into your target root. Then you need to tell the configure script where your cross-compiled headers (yes, header are architecture specific) and libraries are in your target root. Usually using CFLAGS, LDFLAGS, CXXFLAGS, etc (NOT --prefix) but there may be other environment variables you need to set also to affect things like pkg-config, etc. After you have built each dependency, then you need to get the makefile to install the dependency to the root. Usually this is done with make DESTDIR=[root] install but some makefiles have their own mechanism (or no proper alternate install mechanism).
You may also need to override certain configure checks (using environment variables) that are poorly written and don't have good cross-compile defaults. These variables usually start with ac_cv_*
So the basic process is to do this for packages that you need (in dependency order):
export CFLAGS=-I[root]/usr/include LDFLAGS=-L[root]/usr/lib CXXFLAGS=-I[root]/usr/include
export ac_cv_[test1]=[yes|no] ac_cv_[test2]=[yes|no] ...
./configure --host=[arm7-blah-blah]
make
make DESTDIR=[root] install
Good luck. Once you feel comfortable with standard cross-compiling, then you will be ready to take on the real black art, the Canadian cross ;-)
I finally figured it out. I tricked configure by explicitly making it link with ogg (LDFLAGS="/usr/local/ios/lib/libogg-armv7.a" ./configure ...) and then removed the explicit reference to the library from the generated makefile.