I'm using an unordered set for the first time for my Data Structures Class. When I try to run this code on our schools server, it tells me its the wrong architecture. Here is my main code(RAJ.cpp):
#include<iostream>
#include<tr1/unordered_set>
#include "nflData.h"
using namespace std;
using std::tr1::unordered_set;
struct ihash: std::unary_function<NFLData, std::size_t> {
std::size_t operator()(const NFLData& x) const
{
return x.getDown();//Currently just trying to return a value, will not be actual has function.
}
};
int main(){
string a = "20070906_NO#IND,1,46,42,IND,NO,2,6,27,(1:42) P.Manning pass deep left to M.Harrison for 27 yards TOUCHDOWN.,0,0,2007";
string b = "20070906_NO#IND,1,46,42,IND,NO,3,6,27,(1:42) P.Manning pass deep left to [88'] for 27 yards TOUCHDOWN.,0,0,2007";
string c = "20070906_NO#IND,1,46,42,IND,NO,,,27,A.Vinatieri extra point is GOOD Center-J.Snow Holder-H.Smith.,0,0,2007";
unordered_set<NFLData, ihash> myset;
cout << "\ninsert data a";
myset.insert(NFLData(a));
cout << "\ninsert data b";
myset.insert(NFLData(b));
}
And here is the main error I receive when trying to run after successfully compiling with g++:
./test: Exec format error. Wrong Architecture.
It should be noted, this same code works fine when templated for an integer type
You need to compile the program for the type of machine you're going to run it on. The type of machine you compiled this for does not match your school's computer.
If the school has a compiler installed on its server, use it to compile your program.
You can see what type of executable you have with the file command under UNIX, Linux and MacOS X. For example:
$ file /bin/ls # on my Linux box
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
$ file /bin/ls # on my MacBook Pro
/bin/ls: Mach-O usiversal binary with 2 architectures
/bin/ls (for architecture x86_64): Mach-O 64-bit executable x86_64
/bin/ls (for architecture i386): Mach-O executable i386
Usually, different operating systems are able to at least minimally identify executables for foreign systems, but not always. That is, it'll identify that it's foreign, but might not be able to identify which foreign system.
If you are compiling the code on your school's server, then something else strange is afoot. The file command above should help rule out certain things. BTW, you might list out what compiler flags you're using, and the output of file for the version that works and the version that does not.
One other thing to check: Make sure your final compile step does not include the -c flag to g++. That flag tells G++ that you're building an intermediate object, not the final object.
Related
I am beginner regarding gcc command line compilation.
I need a help regarding -m64 flag.
I installed gcc compiler using MinGW.
I checked for gcc version by following,
gcc -v command, which shows Target: x86_64-w64-mingw32.
So I assume, 64-bit version of gcc is installed.
Objective: I wrote a small program to check, if the main.exe is generated for 32 or 64 bit.
#include<stdio.h>
int main(void)
{
printf("The Size is: %lu\n", sizeof(long));
return 0;
}
I compiled using following command, gcc -o main main.c. When I execute the main.exe, it outputs, The Size is: 4.
But I expected the output to be `The Size is: 8'.
So i modified the command as gcc -m64 -o main main.c. When I executed the main.exe again, still it outputs `The Size is: 4'
How to compile for 64-bit version exe?
As others have said in the comments, the size of long can be 8 or 4 bytes on a 64bit system. You can try sizeof(size_t) or sizeof(void*). Even this might not be reliable on every system (but should work for Windows, Linux, macOS).
Here is a better way of doing it.
First download Sigcheck from Microsoft https://learn.microsoft.com/en-us/sysinternals/downloads/sigcheck then run it like below:
C:\Sigcheck>sigcheck64.exe -u -e "C:\Sublime C++ Projects\runtime_measure.exe"
Sigcheck v2.82 - File version and signature viewer
Copyright (C) 2004-2021 Mark Russinovich
Sysinternals - www.sysinternals.com
c:\sublime c++ projects\runtime_measure.exe:
Verified: Unsigned
Link date: 7:43 PM 12/8/2021
Publisher: n/a
Company: n/a
Description: n/a
Product: n/a
Prod version: n/a
File version: n/a
MachineType: 64-bit
As you can see, in this case, runtime_measure.exe is a 64-bit binary.
Don't forget to give the correct address so that the terminal can find and execute sigcheck64.exe from the directory you have placed it.
Also, notice the use of two parameters -u and -e in the command.
x86_64-w64-mingw32:
The mingw32 is compiler that will generate 32bits executables.
The references to 64bit in you package name indicates that this compiler runs in 64bits mode.
If you wan't to generate 64 bits executables, you will need mingw64 compiler:
https://www.mingw-w64.org/
I'm trying to compile C/C++ code from my Debian partition to generate some executable files for Windows.
Running $ uname -a on the command line gives Linux machine 5.14.0-2-amd64 #1 SMP Debian 5.14.9-2 (2021-10-03) x86_64 GNU/Linux. My processor is an Intel® Core™ i5-1035G4 CPU # 1.10GHz × 8, with a Mesa Intel® Iris(R) Plus Graphics (ICL GT1.5) integrated GPU.
A minimal example to show my current situation includes the following code (called code.cpp):
#include <iostream>
#include <CL/opencl.hpp>
int main()
{
std::vector <cl::Platform> all_platforms; //Get all platforms
cl::Platform::get(&all_platforms);
if (all_platforms.size() == 0)
{
std::cout << "No platforms found. Check OpenCL installation." << std::endl;
exit(1);
}
int pz = all_platforms.size();
std::cout << "Platforms size: " << pz << std::endl;
for (int i = 0; i < pz; i++)
{
cl::Platform default_platform = all_platforms[i];
std::cout << "Using platform: " << default_platform.getInfo<CL_PLATFORM_NAME>() << std::endl;
}
return(0);
}
which uses OpenCL to print all recognized devices. I compile my code writing g++ code.cpp -o code.out -lOpenCL. The executable file code.out works fine, doing what you would expect it to do. I have another program which uses GSL (GNU Scientific Library) written in C which also works well, linking with -lgsl (therefore I think there's not a problem with my code or the regular compilation process). Both OpenCL and GSL were installed from the official repositories (~# apt install ...) with no problem at all. When I execute code.out the output is
Platforms size: 2
Using platform: Intel(R) OpenCL HD Graphics
Using platform: Portable Computing Language
I installed mingw (via ~# apt install mingw-w64) to create executable files to be run on Windows, and for basic programs (i.e. without "external" libraries) it works well (replacing gcc by x86_64-w64-mingw32-gcc or i686-w64-mingw32-gcc). However for the code written above (and for the one using GSL) it doesn't work. Most of the error outputs are very similar for both examples, and I will show the command line outputs for the code using OpenCL.
When I try x86_64-w64-mingw32-g++ code.cpp -o code.out -lOpenCL the output is
code.cpp:2:10: fatal error: CL/opencl.hpp: No such file or directory
2 | #include <CL/opencl.hpp>
| ^~~~~~~~~~~~~~~
compilation terminated.
I thought this meant that I needed to be more specific when linking and including, so I gave the explicit path where the headers are located (found them via dpkg -S opencl.hpp or dpkg -S gsl*.h), and the .so file for OpenCL was found via dpkg -S *OpenCL.so, while the one for GSL was found using dpkg -S *gsl.so. When I try x86_64-w64-mingw32-g++ code.cpp -o code.out -I/usr/include/ -L/usr/lib/x86_64-linux-gnu/libOpenCL.so the output is
In file included from /usr/lib/gcc/x86_64-w64-mingw32/10-win32/include/c++/cwchar:44,
from /usr/lib/gcc/x86_64-w64-mingw32/10-win32/include/c++/bits/postypes.h:40,
from /usr/lib/gcc/x86_64-w64-mingw32/10-win32/include/c++/iosfwd:40,
from /usr/lib/gcc/x86_64-w64-mingw32/10-win32/include/c++/ios:38,
from /usr/lib/gcc/x86_64-w64-mingw32/10-win32/include/c++/ostream:38,
from /usr/lib/gcc/x86_64-w64-mingw32/10-win32/include/c++/iostream:39,
from code.cpp:1:
/usr/include/wchar.h:27:10: fatal error: bits/libc-header-start.h: No such file or directory
27 | #include <bits/libc-header-start.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
Therefore it seems that MinGW needs additional instructions to properly find, include and/or link the libraries. I don't know how to solve this problem. Those are my attempts based on some answers I've found, and the documentation provided by MinGW says nothing about this. The exact same problem occurs no matter if I use x86_64-w64-mingw32-g++ or i686-w64-mingw32-g++, or their gcc counterparts.
When cross-compiling make sure you are only linking things targeting the same platform together. In other words, your dependencies (and their dependencies) must be for the same target platform. You can't link with those libraries for your build platform.
So if you have a Windows 64-bit application that depends on OpenCL, you will need to link it against a Windows 64-bit build of OpenCL.
The OpenCL the sources can be found here:
https://github.com/KhronosGroup/OpenCL-Headers
https://github.com/KhronosGroup/OpenCL-ICD-Loader
so you would need to build those first.
Is there a way to determine how many physical cores a target machine has at compile time in C/C++ in Linux under GCC?
I am aware of other methods like td::thread::hardware_concurrency() in C++11 or sysconf(_SC_NPROCESSORS_ONLN) but I am curious to know if there is actually a way to obtain this information at compile time.
You can query information during the build processes and pass it into the program as a pre-processor definition.
Example
g++ main.cpp -D PROC_COUNT=$(grep -c ^processor /proc/cpuinfo)
where main.cpp is
#include <iostream>
int main() {
std::cout << PROC_COUNT << std::endl;
return 0;
}
Edit
As pointed out in the comments. If the target machine differs from the build machine then you'll need to replace the method grep -c ^processor /proc/cpuinfo with something that queries the number of processors on the target machine. The details would depend on what form of access you have to the target machine during build.
I want to load Digital Terrain Elevation(DTED) data using gdal using g++ in solaris 10. In solaris 10, the application with cc compiler loads the data successfully, but when I am using netbeans and g++. the application successfully reads Digital Terrain Elevation(DTED) data but application crashes at GetGeoTranformation(double *) when I print GDALdataset->getDriver()->GetDescription(). This function is working fine in cc. If I comment the line, the application crashes at GDALDataset->GetRasterBand(1), and error prints ld.so.1 fatal reallocation error symbol_ZN11GDALDataset13GetRasterBandIOEi reference symbol not found
Would you mind posting a part of the code which uses GDAL? There could be a few issues. Off the top of my head...
GDAL GetRasterBand starts at 1 when indexing. It seems like your snippet you provided does that.
GDAL requires that you initialize the drivers with GDALAllRegister().
Most GDAL functions return NULL when they return without data. You may want to test that before passing it into another function to prevent potential seg faults.
What does cc point to? I would check the symbolic link with something like
which cc
ls -la /usr/bin/cc (Solaris is Unix, not Linux so forgive me if I am wrong).
I'm trying to compile an run a very basic program given below (test.cpp) which calls the OpenNI class. You can see the files and dirs they're in here. Sorry that some characters screws up a little bit in the browser's encoding. I'm using the linux command: tree, if you know a better command tell me and I will update it.
File Structure
I'm following the guide here, see "GCC / GNU Make".
#include < stdio.h >
#include < OpenNI.h >
using namespace openni;
int
main ( void )
{
Status rc = OpenNI::initialize();
if (rc != STATUS_OK)
{
printf("\nInitialize failed\n%s\n", OpenNI::getExtendedError());
return 1;
}
printf("Hello, world!\n");
return 0;
}
Here is what I'm running in the command line to compile it (gcc 4.7.2):
gcc test.cpp -I../OpenNI-2.0.0/Include -L/home/evan/Code/OpenNi/Init -l OpenNI2 -o test
This works fine but when I run ./test I get the following error:
Initialize failed
DeviceDriver: library handle is invalid for file libOniFile.so
Couldn't understand file 'libOniFile.so' as a device driver
DeviceDriver: library handle is invalid for file libPS1080.so
Couldn't understand file 'libPS1080.so' as a device driver
Found no valid drivers in './OpenNI2/Drivers'
Thanks, any help would be much appreciated.
Instructions from your guide says, that
It is highly suggested to also add the "-Wl,-rpath ./" to your linkage command. Otherwise, the runtime linker will not find the libOpenNI.so file when you run your application. (default Linux behavior is to look for shared objects only in /lib and /usr/lib).
It seems you have exactly this problem -- it can not find some libraries. Try to add proper rpath (seems to be /home/evan/Code/OpenNi/Init/OpenNI2/Drivers in your case) to your compilation string.
I had the same issue after compiling this little "Hello World" with Eclipse and trying to run it in the command line.
The "Wl,-rpath=./" thing did not work for me.
As also discussed here it worked for me after setting some env. variables before execution:
export LD_LIBRARY_PATH="/path/to/OpenNI2:$LD_LIBRARY_PATH"
export OPENNI2_DRIVERS_PATH="/path/to/OpenNI2/Drivers"
export LD_LIBRARY_PATH="/path/to/OpenNI2/Drivers:$LD_LIBRARY_PATH"
Somewhere I got the info that the first two lines should be enough but it was the third line which is important. I does also work just with the third line.