Is it correct, that from pepper 18 onwards, I dont need the scons build system in order to compile, but rather use gcc(nacl-versions) and makefiles?
Also, is it correct that the generated .nexe files will run on any platforms webserver, not just on the platform it was compiled on? So for example, the native code module is developed and compiled under mac os, and generates a 32bit and a 64bit nexe file. The webserver I will load this module on runs on linux, and will still execute the modules in both 32bit and 64bit versions?
Build system for Native Client
No version of the Native Client SDK mandates a particular build system; it has been possible at any time to use SCons, GNU Make, CMake, or even just shell scripts. Put differently, the compilers and tools - which are based on gcc and the GNU toolchain - are independent of the build system the developer decides to use.
However, up to and including the Pepper version 17 of the Native Client SDK, the examples in the SDK came with build files for SCons, and SCons was included in the SDK. From Pepper 18 and onwards this is no longer the case. Instead the build files that are provided for the examples are Makefiles intended for GNU Make.
Also see the release notes for the Pepper 18 version of the SDK.
Cross-compiling
The tools provided in the SDK currently support the 32-bit x86 and 64-bit x86 architectures. The platform of the web server is not important because the Native Client module runs on the client (that is, in the browser). This means there are two systems to consider: the user's system and the developer's system.
On the user's system, when Chrome encounters a Native Client module in a page, it fetches the executable (.nexe file) that's appropriate for the browser on that client. Hence, if a user on 64-bit Windows visits the page, the 64-bit binary will be fetched; if the user is on a 32-bit Mac, the 32-bit binary is fetched. There are exceptions, which I'll treat separately below. Chrome determines the names of the 32-bit and 64-bit .nexes from the manifest file. See the Native Client SDK site (www.GoNaCl.com) for a description and an example of a manifest file
The developer can – and should - produce both 32-bit and 64-bit executables regardless of the operating system and architecture used for development. Running 'make' in the examples/ directory of Pepper 18 and looking at the commands issued is a convenient way of seeing how to do this. E.g., part of the 'make hello_world_glibc' output reads something like:
i686-nacl-gcc -o hello_world_x86_32.nexe hello_world.c -m32 -O0 -g -pthread -O0 -g -Wno-long-long -Wall -lppapi
and
i686-nacl-gcc -o hello_world_x86_64.nexe hello_world.c -m64 -O0 -g -pthread -O0 -g -Wno-long-long -Wall -lppapi
The first line produces the 32-bit .nexe; the second line produces the 64-bit .nexe. The important flag is -m32/-m64, which specifies the architecture - always build both, so that client's on both 32-bit and 64-bit machines can use the app.
Longer term, only one deployment format will be needed, and ARM will be added as a directly supported architecture. See the Portable Native Client project for details.
Here is the specific matching of browser and client architecture to 32/64 bit:
Mac OS (32-bit and 64-bit) -> 32-bit .nexe (Chrome is 32-bit)
Windows (32-bit) -> 32-bit .nexe
Windows (64-bit) -> 64-bit .nexe (Chrome is 32-bit, but starts a 64-bit broker process)
Linux (32-bit) -> 32-bit .nexe
Linux (64-bit) -> 32-bit Chrome fetches 32-bit .nexe; 64-bit Chrome fetches 64-bit .nexe
So as a general rule Chrome fetches the .nexe that matches its own bit-age – except on 64-bit Windows where Chrome fetches the 64-bit .nexe despite being 32-bit itself.
Related
I am trying to install MinGW but it's always failing to install.
on windows 7
link of the program:
https://sourceforge.net/projects/mingw/files/latest/download
Tar zips are not generally for windows users the downlink should be a windows installer mingw-get-setup.EXE thus (not a GnuZip)
Also if your trying to unpack 32bit collections the question is which architecture do you need, certainly 32.exe will run on 64, but 64.exe will NOT work on 32.
Current build is 32bit "Although (currently) offering only a 32-bit compiler suite, all of MinGW's software will execute on the 64bit Windows platforms."
get it from official https://osdn.net/projects/mingw/releases/
latest link I got was
https://osdn.net/frs/redir.php?m=liquid&f=mingw%2F68260%2Fmingw-get-0.6.3-mingw32-pre-20170905-1-bin.zip
once you have a valid windows .zip file, right click to "extract" then the exe should be in the bin folder.
Then it's just you on your own, and the myriad of instructions from google.
MinGW is a compiler generating files for the Windows platform, but MinGW itself can also be run on other platforms (like Linux for example).
What you need is are Windows binaries of MinGW.
But MinGW is a bit outdated and only supports 32-bit Windows.
I would really recommend using MinGW-w64.
Standalone build of MinGW-w64 for Windows (both 32-bit and 64-bit) are available at https://winlibs.com/ just download the archive and extract it. Then all the tools you need will be in the mingw32/bin or mingw64/bin folder.
If you're not very familiar with command line tools you should really use an IDE. There are some instructions on https://winlibs.com/ on how to use MinGW-w64 with Code::Blocks.
If on the other hand you are very familiar with command line or the Linux shell you should take a look at MSYS2 which also allows installing MinGW-w64 with it's pacman tool.
Is there a sort of official documentation about version compatibility between binutils, glibc and GCC? I found this matrix for binutils vs GCC version compatibility. It would be good to have something like this for GCC vs glibc as well.
The point I'm asking this for is that I need to know if I can build, say, cross GCC 4.9.2 with "embedded" glibc 2.2.4 to be able to support quite old targets like CentOS 5.
Thank you.
it's extremely unlikely you'll be able to build such an old version of glibc with such a new version of gcc. glibc documents the min required version of binutils & gcc in its INSTALL file.
glibc-2.23 states:
Recommended Tools for Compilation
GCC 4.7 or newer
GNU 'binutils' 2.22 or later
typically if you want to go newer than those, glibc will generally work with the version of gcc that was in development at the time of the release. e.g. glibc-2.23 was released 18 Feb 2016 and gcc-6 was under development at that time, so glibc-2.23 will work with gcc-4.7 through gcc-6.
so find the version of gcc you want, then find its release date, then look at the glibc releases from around the same time.
all that said, using an old version of glibc is a terrible idea. it will be full of known security vulnerabilities (include remotely exploitable ones). the latest glibc-2.23 release for example fixed CVE-2015-7547 which affects any application doing DNS network resolution and affects versions starting with glibc-2.9. remember: this is not the only bug lurking.
When building a cross-compiler there are at least two, and sometimes three, platform types to consider:
Platform A is used to BUILD a cross compiler HOSTED on Platform B which TARGETS binaries for embedded Platform C. I used the words BUILD, HOSTED, and TARGETS intentionally, as those are the options passed to configure when building a cross-GCC.
BUILD PLATFORM: Platform of machine which will create the cross-GCC
HOST PLATFORM: Platform of machine which will use the cross-GCC to create binaries
TARGET PLATFORM: Platform of machine which will
run the binaries created by the cross-GCC
Consider the following (Canadian Cross Config, BUILD != HOST platform):
A 32-bit x86 Windows PC running the mingw32 toolchain will be used to compile a cross-GCC. This cross-GCC will be used on 64-bit x86 Linux computers. The binaries created by the cross-GCC should run on a 32-bit PowerPC single-board-computer running LynxOS 178 RtOS (Realtime Operating System).
In the above scenario, our platforms are as follows:
BUILD: i686-w32-mingw32
HOST: x86_64-linux-gnu
TARGET: powerpc-lynx-lynxos178
However, this is not the typical configuration. Most often BUILD PLATFORM and HOST PLATFORM are the same.
A more typical scenario (Regular Cross Config, BUILD == HOST platform):
A 64-bit x86 Linux server will be used to compile a cross-GCC. This cross-GCC will also be used on 64-bit x86 Linux computers. The binaries created by the cross-GCC should run on a 32-bit PowerPC single-board-computer running LynxOS 178 RtOS (Realtime Operating System).
In the above scenario, our platforms are as follows:
BUILD: x86_64-linux-gnu
HOST: x86_64-linux-gnu
TARGET: powerpc-lynx-lynxos178
When building the cross-GCC (assuming we are building a Regular Cross Config, where BUILD == HOST Platform), native versions of GNU BinUtils, GCC, glibc, and libstdc++ (among other libraries) will be required to actually compile the cross-GCC. It is less about specific versions of each component, and more about whether each component supports the specific language features required to compile GCC-4.9.2 (note: just because GCC-4.9.2 implements language feature X, does not mean that language feature X must be supported by the version of GCC used to compile GCC-4.9.2. In the same way, just because glibc-X.X.X implements library feature Y, does not mean that the version of GCC used to compile glibc-X.X.X must have been linked against a glibc that implements feature Y.
In your case, you should simply build your cross-GCC 4.9.2 (or if you are not cross compiling, i.e. you are compiling for CentOS 5 on Linux, build native GCC 4.9.2), and then when you link your executable for CentOS 5, explicitly link glibc v2.2.4 using -l:libc.so.2.2.4. You also probably will need to define -std=c99 or -std=gnu99 when you compile, as I highly doubt glibc 2.2.4 supports the C 2011 standard.
I've tried to compile my source files using minGW-w64, because of new C++14 standard but when i try to compile i got this error even all things and setup is allright i guess:
Execution of 'g++.exe -c C:\Users\Denis\Desktop\isocpp.cpp -o C:\Users\Denis\Desktop\isocpp.o' in 'C:\Users\Denis\Desktop' failed.
MinGW-w64 Screenshot
My PC version is 32bit, from the official site i was notified that MinGW-w64 works for 64-32bit.
There are two distinctions to make here:
Whether gcc.exe is a 32-bit binary or a 64-bit binary
Whether that binary will generate programs that target 32-bit or 64-bit
mingw-w64 supports all four possible combinations here. But it sounds like you have downloaded a 64-bit binary. 32-bit Windows cannot run 64-bit binaries.
To fix this, use the official installer (warning:Sourceforge, although it is not hosted anywhere else so far as I know), or look out when downloading prepackaged builds.
I have a Windows console app that is pure standard C++. I am building it in Cygwin 1.7.16 (running on Windows 7) for target Cygwin 1.5.24 (running on Windows XP SP 2).
My build command is:
g++ -o mgen_stats.exe -I ../include ../src/*.cpp
On the target, my path includes /usr/bin, which is where cygwin1.dll lives.
When I run the application with no arguments on the target in a Cygwin 1.5.24 shell, I immediately get the command prompt back. I should see the application's usage printed out.
Some immutable constraints I'm working under:
The build and target machines are isolated from each other.
There is no C++ build tool chain on the target.
I may not install a C++ build tool chain on the target.
I may not modify the C++ build tool chain I have on the build machine.
As a result of the above, I must build on my build machine, burn the .exe to a CD, and copy it onto the target machine.
I would be just as happy for my application to be a native Windows application (i.e. run it in a DOS shell rather than a Cygwin 1.5.24 shell). To this end, I tried using g++ build flag -mno-cygwin. g++ tells me that flag -mno-cygwin has been removed. It then suggests that I "use a mingw-targeted cross-compiler". I do not know how to tell if I have the mingw-gcc, mingw64-i686-gcc, and mingw64-x86_64-gcc packages (which, according to the Cygwin FAQ, contain the suggested cross-compilers), and if I do have them, I do not know what the names of the compiler executables are.
Can anybody help me get this app built such that it will run successfully under either a DOS or Cygwin 1.5.24 shell on my Windows XP SP 2 target?
Thank you in advance.
The MinGW packages (like any other Cygwin package) can be installed on Cygwin using the "setup.exe" that Cygwin provides on its website. If you do have them installed, you'll find the compilers as i686-w64-mingw32-g++ or x86_64-w64-mingw32-g++.
Alternatively, you can also install the MinGW packages directly (without using Cygwin).
I am attempting to setup a small build cluster at home using distcc. There are two x64 systems and 1 i686 systems. All systems are running Ubuntu 10.10 and are up to date. The system that is initiating the build is x64. Distcc works fine between the two x64 systems but all build tasks sent to the i686 system fail.
So far:
I have installed the multilib package for g++ on that system. I am able to cross-compile to x64 locally using g++ -m64
Changed the link in /usr/lib/distcc/g++ to point to a script that explicity sets the -m64 parameter.
Any suggestions?
Attempting this one again after more research:
GCC has a page describing the i386 and x86-64 options. The -m64 flag says to generate 64-bit code, but you'll also want to specify the type of CPU with -march=i686 or -march=k8 or similar, to use the correct instruction set.
Since distcc sends the GCC command line flags out, you should try adding these to the distcc command running locally and skip the remote script for setting flags.
If you test the architecture flags on your local x64 machine without distcc, just g++, then it should give you the right binaries when using distcc.