I keep getting the same error on a simple piece of code after I downloaded multiple compilers and added them to 'PATH' in windows settings
Error :
E:\Programs\sublimeProjects\helloWorld: file not recognized: File format not recognized
collect2.exe: error: ld returned 1 exit status
[Finished in 985ms]
I downloaded multiple compilers and added them to 'PATH' in windows settings
This is a very bad idea. You will run into a complete mess where parts of one compiler interfere with parts of the other compiler due to them all being on the PATH.
I would recommend to immediately remove all compilers from the PATH. Instead, what you should do is have a batch file or shell script that you run to set up the environment for just that window.
Some compiler installations come already set up this way (e.g. mingw-w64/MSYS2).
In SublimeText you can set it to use that batch file or script to set up the build environment, e.g. see https://gist.github.com/sagebind/9039773048a3900fa49a .
Related
I attempted to follow through on VS Code's method on making C++ code work on their editor. I did this successfully on my laptop but when I tried compiling it, I was met with the error:
* Executing task: C/C++: g++.exe build active file
Starting build...
C:\msys64\mingw64\bin\g++.exe -fdiagnostics-color=always -g "C:\Users\salty\Documents\Programming\C++ Scripts\myProgram\main.cpp" -o "C:\Users\salty\Documents\Programming\C++ Scripts\myProgram\main.exe"
'cmd' is not recognized as an internal or external command,
operable program or batch file.
Build finished with error(s).
* The terminal process failed to launch (exit code: -1).
* Terminal will be reused by tasks, press any key to close it.
This is the entire error message plus extra things in my editor.
If I try and copy and paste the command in the message into Windows Power Shell, it actually works (New .exe file appeared in the correct directory and runs without fault).
These are my environment variables for User, and these are my System variables.
I've tried uninstalling and re-installing and changing the paths around. I'm new to C++ programming and how compilers work in general, but I'm not sure why VS Studio says it doesn't recognize cmd among others it could've not recognized.
Why is it giving me this error?
Edit: I believe I didn't include a return 0; line in the program. Correcting this did not fix the issue.
I am not sure what I poked into place or if I just was too incompetent to realize something, however adding %SystemRoot%\system32 to my PSModulePath environment variables somehow fixed the issue, and since that action I have yet to replicate the compile error.
I don't know if adding that variable to my environments permanently fixed it or VS Studio needed a moment to process some things. Thanks anyways!
I'm trying to run my C++ program on my Macbook and I'm trying to run my program in VSCode by running the build task C/C++:clang++ build active file. However, every time I do this I get this error ld: can't open output file for writing: /Users/admin/first/first, errno=21 for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) The terminal process terminated with exit code: 1
This appears to be a simple permission problem here:
ld: can't open output file for writing
The linker cannot write to the file specified.
Edit: As correctly pointed to by molbdnilo, the error 21 is EISDIR, which means the file you are trying to write to already exists as a directory. So ... just this folder? :)
Did you brew install any c++ tools? Sometimes that is the source of these issues. The program is trying to use native OS versions of things when it should use Homebrew's or vice versa.
Disclaimer: I am new here, I've done my best to follow the posting guidelines so please let me know if this needs any extra information. I am also relatively new to Linux development.
Background:
I am in the process of building a library using ActiveMQ-cpp on Linux. I have built and run it successfully on the host Ubuntu PC, but attempting to cross-compile it for the target ARM-based machine is producing some very abstruse errors.
The first step involves building APR (http://apr.apache.org/) using the arm-linux-gcc compiler. After some research, the following command runs the configuration script with little fuss:
CC=/usr/local/arm-linux/bin/arm-linux-gcc ./configure --prefix=/root/apr-arm --host=arm-linux cross_compiling=yes ac_cv_file__dev_zero=no ac_cv_func_setpgrp_void=no apr_cv_tcp_nodelay_with_cork=no apr_cv_process_shared_works=no
This allows the next step - running the makefile.
Current Issue: Entering make on the command line exits prematurely at the following line:
[...]
/root/.local/share/Trash/files/apr-1.5.1/build/mkdir.sh include/private
tools/gen_test_char > include/private/apr)escape_test_char.h
/bin/bash: tools/gen_test_char: cannot execute binary file
make[1]: *** [include/private/apr_escape_test_char.h] Error 126
make[1]: Leaving directory `/root/.local/share/Trash/files/apr-1.5.1'
make: *** [all-recursive] Error 1
Attempted Fixes: A solution to the following question, posted by the asker, has not worked. It is possible that I've not followed the process correctly (Apache Cross Compilation Error ./gen_test_char: cannot execute binary file)
In the same theme, I tried temporarily removing the problem gen_test_char program from its directory but the clever script just rebuilds it.
My aim is to either avoid this error and continue the build process on Ubuntu, or perhaps consider other means of building the library. I have built it with no trouble in VS2013 on Windows, so if it is possible to cross compile that project for ARM architectures I would happily go ahead with that.
APR need gen_test_char to be compiled for system not for arm, why you got "bin/bash: tools/gen_test_char: cannot execute binary file" error because make program is going to execute gen_test_char on your system and if you cross compile then every time you got this error.
To avoid this error please follow below steps:
1) Cross compile APR which is going to fail
2) compile APR for system and copy gen_test_char to cross compiled APR's directory.
3) Again cross compile
After performing above steps you should not get "cannot execute binary file" error.
Cross compile APR which is going to fail
compile APR for system and copy gen_test_char to cross compiled APR's directory.
change the name of gen_test_char to gen_test_char_host
in Makefile file change the name of gen_test_char to gen_test_char_host because make creates it again.
Again cross compile
you may see some struct redefinition which needs to find the file and comment the redefined struct manually.
I'm trying to create postgresql plugin for Symbian device but I can't compile it. I'm working on Windows 7 64bit.
I did everything according to this article: http://doc.qt.io/archives/qt-4.7/sql-driver.html#qpsql
C:\QtSDK\QtSources\4.8.1\src\plugins\sqldrivers\psql>qmake "INCLUDEPATH+=C:\Program Files (x86)\PostgreSQL\8.3\include" "LIBS+=C:\Program Files (x86)\PostgreSQL\8.3\lib\libpq.lib" psql.pro
WARNING: (internal):1: Unescaped backslashes are deprecated.
So, it looked OK. Then...
C:\...drivers\psql>C:\QtSDK\Symbian\tools\sbs\win32\mingw\bin\make debug-gcce
sbs -c arm.v5.udeb.gcce4_4_1
python.exe is not recognized as an internal or external command, operable program or batch file.
make: *** [debug-gcce] Error 9009
I noticed, that sbs_home was set to python directory but it was not in the path, then the make could not find the script raptor_start.py:
C:\...drivers\psql>echo %sbs_home%
C:\QtSDK\Symbian\tools\sbs\win32\python27
C:\...drivers\psql>set path=%path%;%sbs_home%
C:\...drivers\psql>C:\QtSDK\Symbian\tools\sbs\win32\mingw\bin\make debug-gcce
sbs -c arm.v5.udeb.gcce4_4_1
python.exe: can't open file C:\QtSDK\Symbian\tools\sbs\win32\python27\python\raptor_start.py': [Errno 2] No such file or directory
make: *** [debug-gcce] Error 2
C:\...drivers\psql>set sbs_home=C:\QtSDK\Symbian\tools\sbs
so, when I started compiling I got this error:
C:/QtSDK/Symbian/SDKs/Symbian3Qt474/epoc32/include/stdapis/stlportv5/stl/_istream.c:650: warning: suggest parentheses around '&&' within '||' target : epoc32\release\armv5\udeb\qsqlpsql.dll [arm.v5.udeb.gcce4_4_1]
FAILED linkandpostlink for arm.v5.udeb.gcce4_4_1: epoc32\release\armv5\udeb\qsqlpsql.dll
mmp: qsqlpsql_dll.mmp
c:/qtsdk/symbian/tools/gcce4/bin/../lib/gcc/arm-none-symbianelf/4.4.1/../../../../arm-none-symbianelf/bin/ld.exe: warning: C:/QtSDK/Symbian/SDKs/Symbian3Qt474/epoc32/release/armv5/udeb/usrt3_1.lib(ucppinit.o) uses variable-size enums yet the output is to use 32-bit enums; use of enum values across objects may fail
C:/QtSDK/Symbian/SDKs/Symbian3Qt474/epoc32/build/psql/c_8d95259b570e1766/qsqlpsql_dll/armv5/udeb/qsql_psql.o: In function `qMakeError': C:/QtSDK/QtSources/4.8.1/src/sql/drivers/psql/qsql_psql.cpp:175: undefined reference to `PQerrorMessage'
....many undefined references...
C:/QtSDK/QtSources/4.8.1/src/sql/drivers/psql/qsql_psql.cpp:117: undefined reference to `PQfreemem'
collect2: ld returned 1 exit status
mingw32-make[1]: *** [C:/QtSDK/Symbian/SDKs/Symbian3Qt474/epoc32/release/armv5/udeb/qsqlpsql.dll] Error 1
sbs: error: The make-engine exited with errors.
sbs : warnings: 3
sbs : errors: 2
built 'arm.v5.udeb.gcce4_4_1'
Run time 5 seconds
sbs: build log in C:\QtSDK\Symbian\SDKs\Symbian3Qt474\epoc32\build\Makefile.2012-06-26-15-03-12.78-2996.log
make: *** [debug-gcce] Error 1
Has anybody idea, what with it?
You are trying to build an Symbian/ARM application using precompiled binary postgresql client library for Windows. This won't ever work. The instructions you refer to only show how to build for OS X, Unix and Mac targets natively. You're cross compiling for Symbian.
You'd first need to obtain a binary version of the postgresql client library compiled for Symbian. It might exist out there, or you may need to compile it yourself. I don't think that the library supports Symbian as a target, and I couldn't readily find any Symbian ports for download. You may be out of luck for a trivial solution. A port might not be entirely out of the question, though -- perhaps the platform-specific code is localized enough.
I have a batch file that tries to compile a static library using Borland C++ Builder 6.0
It is called from Borland make (makefile created with bpr2mak) which is called from a .bat file (used to compile the whole project with Visual Studio and some Borland C++ Builder legacy projects), which is called from a bash shell script running inside Cygwin.
When I run the .bat file directly from a Cygwin shell, it runs OK, but when its being run from a Program calling cygwin with Boost::Process::launcher I'm getting this error:
C:\ARQUIV~1\Borland\CBUILD~1\Bin\..\BIN\TLib /u bclibs.lib #MAKE0000.###
DOS-reported error: Bad file number
TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation
opening 'MAKE0000.###'
** error 1 ** deleting bclibs.lib
It's a complicated scenario, but this Program which calls cygwin is run whenever we need to build our software package which needs to be build for various Linux distos and Windows 32 and 64-bit.
Note: It's the only Borland Project failing, the other compile just fine (it's the only static library using borland also, so it can be some problem with the TLib tool.
The problem was that TLib does not like to have his output redirected (seen here) without having an input pipe as well. Solved by creating an input pipe to in the Boost::Process::launcher using set_stdin_behavior
I'm just guessing here, but this may have to do with long filenames and/or spaces in paths.
1) Modify your makefile so it would save current environment to a file, immediately before executing the failing command (set > d:\env.txt & echo CD=%CD% >> d:\env.txt). Then run it both ways (directly and via program) and compare the environments of good run and bad run.
2) Using filemon from Sysinternals, capture logs of disk access in both cases (these logs are going to be huge, though you can uncheck everything except Open in the filter to reduce the size). Again, compare and check for clues...
3) Try instaling everything involved to paths conforming to 8.3 scheme.
This error is not related to C++ itself. It happens when your build script opens too much files (more than defined in DOS command processor environment). To resolve this issue try to set value of files variable to 253. For Windows XP this variable defined in the file %WINDIR%\system32\config.nt.
files=253
Seems it is known bug in Borland C++ tools. Here is description and possible workaround for this issue:
Problem: Some static Lib projects will
not link correctly when compiled. You might see something
like this :
J:\Borland\CBUILD~1\bin\..\BIN\TLib /u debug\jpegD.lib #MAKE0000.###
DOS-reported error: Bad file number
TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation
opening 'MAKE0000.###'
** error 1 ** deleting debug\jpegD.lib
MAKE failed, returned : 1
Workaround : In some cases (where the "Bad file number" error is seen) it may be possible to work around this by specifying -tDEFLIB.BMK in the BPR2MAKE Options field, and Turning off the "Capture Make Output" option.
I have not tested it, but I hope that helps.