If I compile this QT c++ program in SuSE Linux
#include <iostream>
using namespace std;
int main ()
{
cout << "Hello World!";
return 0;
}
When I type
i386-mingw32-g++ helloworld.cpp
I get the following error
i386-mingw32-g++: error trying to exec 'cc1plus': execvp: No such file or directory
Is this because MinGW package which i installed contains only gcc in it.. hence i downloaded gcc-g++-3.4.5.rpm package and just copy pasted i386-mingw32-g++ and cc1plus executable along with C++ include files.
Pls reply.
Thanking You
Ugh. The cc1plus in gcc-g++-3.4.5.rpm is not for mingw32. You need the one for your distro.
e.g. for Fedora 10, use http://sourceforge.net/projects/outmodedbonsai/files/Mingw%20Cross-compiler/mingw-1.10-1.fc10.x86_64.rpm
Quoting from here:
It means that your shell could find
the g++ frontend of the GNU compiler
but that frontend couldn't find
cc1plus, the actual C++ compiler; it
could find cpp, the preprocessor, it
already ran. Go to the directory where
the g++ frontend is stored (type:
"which g++") and look for the file
cc1plus in that same directory or a
sub- directory thereof. If it isn't
there your compiler installation is
broken; if it is there some
configuration of it went berzerk.
Also, have a look at this thread.
suse cross-compile toolchain is here.
http://download.opensuse.org/repositories/CrossToolchain:/mingw/
Related
I am starting in the world of LLVM and searched in several places and read several documentation about LLVM but I found nothing showing how to compile a program that uses LLVM headers and libs ....
I wrote this simple program just to try to compile, using the Visual Studio cross-compiler, I tried several command line options .... even using the -lLLVM option, but, nothing worked ...
I tried using g++ and clang++
#include <iostream>
#include <llvm/ADT/OwningPtr.h>
#include <llvm/Support/MemoryBuffer.h>
int main()
{
llvm::OwningPtr<llvm::MemoryBuffer> buffer
return 0;
}
When I try to build, I get this erro:
error : 'llvm/ADT/OwningPtr.h' file not found
So, what is the command line to compile this simple program?
The command llvm-config --cxxflags --ldflags --system-libs --libs core will provide you with all the linkable llvm libraries, provided you have llvm installed. Just link with this command in single quotes
I've tried official howto but failed. I got error:
"The procedure entry point InterlockedCompareExchange#12 could not be located in the dynamic link library libstdc++-6.dll"
The problem was due the old gcc compiler, bundled with DevKit from rubyinstaller.org (4.5 vs 4.8 on my PC). Use MSYS instead. Assume we have zeromq source inside D:\libs\zeromq, then the procedure is:
Download GUI MinGW installer.
Install base and MSYS (if you already have working gcc compiler you probably only need MSYS).
Launch MSYS environment by executing C:\MinGW\msys\1.0\msys.bat.
Follow Using MSYS with MinGW section:
mount c:/mingw /mingw
cd /d/libs/zeromq
./configure --prefix=/mingw
make
Copy /d/libs/zeromq/src/.libs/libzmq.dll to your desired place.
In fact I needed to use ZeroMQ with C++, so I downloaded zmq.hpp, moved it to include directory, and compiled hwserver.cpp to test it:
C:\MinGW\bin\g++.exe -o hwserver hwserver.cpp -L. -lzmq -ID:\libs\zeromq\include
It worked, but when I launch it I got:
Assertion failed!
Program: D:\tmp\zmq\hwserver.exe
File: D:\libs\zeromq\include/zmq.hpp, Line 280
Expression: rc == 0
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
I've managed to get rid of this failure by commenting lines 279, 280. Similar issue
I want to have local installation (in my home-folder (Linux), say $HOME/boost) of the boost C++ libraries in addition to a system-wide installed default of the boost libs. I built them from sorce and that worked fine.
After that, I set the environment variables CPLUS_INCLUDE_PATH and LD_LIBRARY_PATH to match the destination of the local installation, so both pointing to $HOME/boost/include and $HOME/boost/lib/, respectively.
In order to test that, I used the following code for testing the correct usage of CPLUS_INCLUDE_PATH for the headers:
#include <boost/version.hpp>
#include <iostream>
#include <iomanip>
int main()
{
std::cout << "Boost version: " << BOOST_LIB_VERSION << std::endl;
return 0;
}
Compiling it with g++ -o Test_boost_version test_boost_version.cpp works as expected, reporting the expected (local) version. Having CPLUS_INCLUDE_PATH empty gives me the boost-version of the default, system-wide installation. So far so good.
In order to test the linking, I used the following code (taken from the boost homepage:
#include <boost/regex.hpp>
#include <iostream>
#include <string>
int main()
{
std::string line;
boost::regex pat( "^Subject: (Re: |Aw: )*(.*)" );
while (std::cin)
{
std::getline(std::cin, line);
boost::smatch matches;
if (boost::regex_match(line, matches, pat))
std::cout << matches[2] << std::endl;
}
}
and built it with g++ -o Test_boost_linking test_boost_linking.cpp -lboost_regex.
Calling ldd Test_boost_linking however does NOT make use of the local installation (provided via LD_LIBRARY_PATH) but gives me: libboost_regex.so.1.42.0 => /usr/lib/libboost_regex.so.1.42.0 (0x00007f9264612000)
When I use g++ -o Test_boost_linking test_boost_linking.cpp -lboost_regex -L$HOME/boost/lib, ldd is reporting the correct library (libboost_regex.so.1.50.0 => $HOME/boost/lib/libboost_regex.so.1.50.0 (0x00007f6947d2a000)).
This is actually a problem for me since I want to set up my local environment such that a compilation will ignore the system-default boost installation and only use the local installation and I thought this is exactly what is achieved when setting the CPLUS_INCLUDE_PATH and LD_LIBRARY_PATH, but for the latter, this seems not to hold true.
So how can I make sure that using g++ -o Test_boost_linking test_boost_linking.cpp -lboost_regex (without -L) uses the local libraries?
[EDIT] Thinking of it further, I am wondering IF it is actually absolutely mandatory to use "-L$HOME/boost/lib" in the command-line (using LDFLAGS as environment variable seems to have no effect, probably just in combination with a Makefile) when using libraries in a non-standard directory?? Is this the case?
(BTW I think this will hold true also for other libraries, not only boost...)
(I used: g++ (Debian 4.4.5-8) 4.4.5)
Thank you.
You need to use the environment variable LIBRARY_PATH to let gcc know where to find the libraries at link time. LD_LIBRARY_PATH lets the program know where to find the dynamic libraries at runtime. This answer has more details. These links from "An Introduction to GCC" may also be useful: Compilation options:Environment Variables and Shared and Static Libraries
Hi I'm learing Lex and yacc. I created the following lex program.
%{
#include <stdio.h>
%}
%%
[0123456789]+ printf("NUMBER\n");
[a-zA-Z][a-zA-Z0-9]* printf("WORD\n");
%%
I'm trying to run it using the following commands:
lex example1.l
cc lex.yy.c -o example1 -ll
also tried cc lex.yy.c -o example1 -lfl
When I enter the second command form above, I get error:
D:\workdir\flexyacc\Test3>gcc lex.yy.c -o Test -lfl
C:\Dev-Cpp\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -lfl
collect2: ld returned 1 exit status
I tried googling this error but no luck so far. Since I'm new in Lex programming, I'm not understanding how to fix this. Any help will be greatly appreciated. Thank so much in advance.
If you are using lex + yacc you can remove -lfl if you define yywrap function or, even better, if you use noyywrap option:
%option noyywrap
%%
...
%%
To compile the lex code, firstly you should have installed flex in your machine.
If so , there will a file libfl.a. In my machine I've installed flex in 'C:\GnuWin32\lib'
gcc lex.yy.c -L"C:\GnuWin32\lib" -lfl
I encountered the same problem and so i checked it out in the Internet and found a solution by workingcaptchabypass posted June 3, 2011 6:44 PM here
he said:
You could add this function instead and compile normally
yywrap()
{
}
And so i supplied the code in the .lex file before the main function. After doing that, it worked out the way it should :)
I have run into this issue when porting TXR to Windows using MinGW.
MinGW has a flex library for itself, but does not export it to the environment.
See here: http://lists.nongnu.org/archive/html/txr-users/2011-10/msg00001.html
The workaround is to use -L/usr/lib before -lfl. But think about this: it is a hack. Why? Because the path /usr/lib/ belongs to MinGW, the compilation environment's run-time.
/usr/lib is not where the toolchain is supposed to find libs for the Windows program being built (which is it's not in the library search path!)
That is to say, we are effectively stealing the build machine's native library in a cross-compile job.
This is like if you were cross-compiling, say, a Fedora program on Ubuntu, and helping yourself to Ubuntu's static library in /usr/lib that happens to be missing in the Fedora cross toolchain (taking advantage of the fact that the architecture and object file format happens to be the same).
It's definitely a bug in the way Flex is "packaged" in MingW.
After having a hard time trying to fix the same problem as yours, I installed flex-old:
sudo apt install flex-old
Try using -ll instead of -lfl in gcc
If you are on macOSX then replace -lfl with -ll
For error:
cannot find -lflx
In your Makefile change:
LEXLIB = -lfl to LEXLIB =.
Otherwise remove the -lfl argument wherever present.
Hi i am a beginner learning objective c.
i am finding an error "hello.m:1:34: Foundation/Foundation.h: No such file or directory"
i came to know that i need to make a make file
may i know how to make the make file please
No need to create a makefile. If you start MinGW from "All Programs -> GNUstep -> Shell" as Pax indicates above, you can just compile your .m file.
My GNUstep installation is in c:\GNUstep\GNUstep\System. If yours is different, you should change the import of Foundation.h accordingly.
I did this:
Create c:\myprogs\obj-c\hello\hello.m that looks like this:
//---------- Hello.m
#import <../../GNUstep/System/Library/Headers/Foundation/Foundation.h>
int main(int argc, const char* argv[])
{
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
NSLog(#"Hello from Hello.m!");
[pool release];
return 0;
}
//----------
Start MinGW shell. (See above.)
On shell command line, change to directory where program code is located. (Note that, since this is not Unix, the Windows drive letter must be included.):
cd /c/myprogs/obj-c/hello
Compile the program:
gcc -o hello hello.m -I/c/GNUstep/GNUstep/System/Library/Headers \
-L /c/GNUstep/GNUstep/System/Library/Libraries -lobjc -lgnustep-base \
-fconstant-string-class=NSConstantString
(Note that "\" character allows us to extend command to multiple lines.)
I get the following informational messages when I compile:
Info: resolving ___objc_class_name_NSAutoreleasePool by linking to __imp____objc_class_name_NSAutoreleasePool (auto-import)
Info: resolving ___objc_class_name_NSConstantString by linking to __imp____objc_class_name_NSConstantString (auto-import)
Running resulting hello.exe gives me this:
2009-06-03 14:44:59.483 hello[1240] Hello from Hello.m!
That problem just looks like you haven't instructed gcc on where to find the relevant include files (i.e., the directory in which Foundation/Foundation.h resides).
Are you running gcc from under MinGW or from the command prompt. You should have a "All Programs -> GNUstep -> Shell" on your Start menu which brings up this shell.
A makefile for this should be as simple as:
include $(GNUSTEP_MAKEFILES)/common.make
TOOL_NAME = YourProg
YourProg_OBJC_FILES = source_code.m
include $(GNUSTEP_MAKEFILES)/tool.make
If you will put your source codes into home directory in GNUStep, you don't need to provide relative location of Foundation framework.
Using a makefile such as the one specified by paxdiablo is probably the easiest, because rather than trying to remember an arcane command line each time, you set up the makefile and then call make from the source folder.
However, my experience under Windows suggested that GNUStep and Windows, even with the shell, won't build using that because it can't find all the make files it needs - add an environment variable GNUSTEP_MAKEFILES with a value of /GNUstep/System/Library/Makefiles and restart that shell, and then any errors from it being unable to find the standard makefiles should be history.
(I had tried using full paths to the makefiles, but found that this included the specific makefiles but then failed when trying to include further ones, hence going the easy route and adding an environment variable.)