I'm hoping someone has come across this problem before too.
I am trying to use visual studio to develop for Linux with G++.
I am trying to include math.h and use tanf()
If I compile with the g++ compiler, "arm-none-linux-gnueabi-g++", everything works
but if I add this include directory, which the docs say is the right one, and
"CodeSourcery\Sourcery G++ Lite\arm-none-linux-gnueabi\libc\usr\include\"
then include math.h,
visual studio does not recognize any of the math functions, namely tanf().
anyone have any idea why?
thanks for any help.
edit:
the same app successfully compiles with this command line:
arm-none-linux-gnueabi-g++ -o test main.cpp "-I%PALMPDK%\include" "-I%PALMPDK%\include\SDL" "-L%PALMPDK%\device\lib" -Wl,--allow-shlib-undefined -lSDL -lGLESv2 -lpdl
I am trying to use visual studio to develop for Linux with G++.
Don't.
It looks like you are trying to use a cross compiler to build for an embedded ARM machine. Likely, you won't be able to get away with just the compiler - you'll need a whole root environment in order to link to anything more than libc. Visual Studio, while a good IDE, really can't be molded into this role. You will really need an actual Linux machine, with your corresponding root environment (be it home grown, buildroot, openembedded, etc).
1) In C++, you include <cmath>, not math.h.
2) in C++, you use tan with float arguments (there is an overload), not tanf.
I would guess that Visual Studio sees <math.h>, and thinks that must refer to the Microsoft math header (which is fundamentally antediluvian and lacks support for C99 niceties such as tanf). This is just guessing though, since you haven't posted the actual error that you're encountering; what exactly do you mean when you say "visual studio does not recognize any of the math functions"? Does it fail to compile? To link? What is the exact text of the error message? What are the exact options that are being passed to the compiler or linker?
I found a solution!
I downloaded and installed MinGW instead, and that works fine. I have all the function prototypes for extra stuff like gettimeofday(), and all the regular suff like tanf() is still working fine.
ps: visual studio even has a button for "Use Output Window" where it nicely dumps any errors that are generated by "arm-none-linux-gnueabi-g++"
Related
I've been using qtcreator with an scons build, and for the life of me I can't get it to recognise the compile errors/warnings and put them in the build issues tab
The only difference I can see is that whereas the qmake output is something along the lines of
..\..\myfile.cpp:123:4 error xyz not declared in this scope
the scons output is along the lines of
project\subproject\myfile.cpp:123:4 error xyz not declared in this scope
as the scons build doesn't keep changing directory and builds from elsewhere.
Is there anything I can do to persuade QTCreator to look for the files in the right place, find them, and then add the appropriate line to the build issues tab,
Well, I have an answer (sort of).
I created a custom compiler which pointed to the studio compiler (not a clone) and changed my kit to use that.
Then I did a compile
Then I changed back to the microsoft visual studio compiler.
And now it works.
I have no idea why
I just installed qt creator sdk and the windows debug thing. When I try to debug the debugger comes with the warning:
Preferred debugger engine for debugging binaries of type 'x86-windows-msys-pe-23bit' is not available.
The debugger engine Cdb engine will be used as a fallback
Details: There is no gdb binary available for binaries in format 'x86-windows-msys-pe-32bit'
Then the program start building.
When I set breakpoints into the program the debugger won't stop at de breakpoints. I've tried a lot of things to let the debugger work properly but nothing has helped so far. If anybody has a suggestion please let me know. I think it maybe has something to do with the compiler I'm using which is something like mingw but i have no idea how to set another compiler or something like that
Since you do not know msys, most likely you do not need the msys compiler, try mingw compiler itself from here.
make sure to install gcc, and gdb.
Since you did not mention I assume it is Windows, as a side note, if gdb gave you headache on Windows please use the mingw version bundled with Code::Blocks it is probably older though (look for the one that comes with mingw bundled).
You need to get either gdb/cdb installed with Qt to be able to debug your code. Try editing the options in Tools->Options in Qt Creator and pointing to correct gdb paths. That should solve this problem. There are other options available there to configure the gdb options in the settings dialog.
I come from UNIX world, I'm quite familiar with Linux, Solaris, Cygwin
and MinGW development. Recently I ported one of my
big projects (cppcms) to support MSVC,
including building static and dynamic libraries with CMake.
And I get all the time absolutely weird issues:
I had CMake build issues because Windows programming
lacks naming convention
for import and static libraries.
Now I discovered that I should use different versions of ICU (debug/release builds) according to the
actual build I do (Debug/RelWithDebInfo -- should use Debug ICU, Release release ICU) and so I should
change actual conventions for searching libraries according to debug/release mode only under MSVC.
Otherwise application just would not start giving a error on missing DLL.
I don't have any such issues under Mingw or Cygwin with GCC, Open Solaris with Sun Studio or Linux with gcc or intel compilers.
And I still have numerous wired issues and wired bugs and very strange behavior -- even some trivial things do not work
under MSVC builds, when everything works absolutely fine under Solaris/Linux/Cygwin/Mingw using GCC from 3.4 up to 4.4,
Sun Studio and Intel compilers). But not under MSVC.
To be honest, I have no idea how to deal with Last one! Because it looks like for me more like environment issues.
I know that the question is not really well defined. I think I'm quite experienced
developer and I know how to write portable and good C++ code. But using Microsoft native
tools drives me crazy with issues I just don't know how to solve.
Question: What should experienced Unix programmer with quite good base in Win32 API should know when it
starts using Genuine Microsoft Tools?
P.S.: Can someone explain why "Release With Debug Info" requires Debug version of MSVC runtime? And why there two versions of runtime exist at all?
P.P.S.: Please note I don't have issues with Win32 API, in fact Windows GCC build works absolutely fine.
Clarifications:
I'm looking for pitfalls that programmer that come from Unix world would may fall into.
For example, when moving from Linux to Solaris: make sure you compile code with -mt or
-pthreads when using multi threaded programs, linking with -lpthread is not enough.
P.S.: Can someone explain why "Release
With Debug Info" requires Debug
version of MSVC runtime?
It doesn't.
And why there
two versions of runtime exist at all?
Because the debug version does more error checking.
And I still have numerous wired issues
and wired bugs and very strange
behavior -- even some trivial things
do not work under MSVC builds,
* What am I doing wrong?
Not telling us what "wired issues and wired bugs and very strange behavior" you get.
* Where should I start?
By telling us the specific errors and problems you encounter.
* What do I miss?
Reading the documentation and learning the tools.
If your question is "What do I read to become a good Windows programmer?" then my answer is: Everything from Jeff Richter, as a start.
There is no magic bullet which will automatically make you an experienced Windows developer. Windows is a very different land compared to Unix. There are lots of quirks, weird behavior, and stuff which is just plain different. The only way to get out with your sanity intact is to tackle the transition one small problem at a time. Concentrate on a specific problem and try to understand the problem. Don't just "get it to work", but really understand what is happening. A good book about Windows programming will help.
There are huge amounts of Windows knowledge and experience accumulated in the SO community, but the only way to access it is to ask concrete questions about specific problems.
The release and debug versions of DLL's use different ways of allocating memory, that is why it is not advisable to mix release and debug versions. If you allocate something in a debug mode DLL and pass it back to the application which was compiled in release mode you may get into trouble.
In the case of your naming issues you may want to have different directories where you place your static / dll's. You can do do this in visual studio by using the configuration manager, not sure how it is under the express version.
I think you need to try and actually understand the new toolset rather than just try and squish it into your current understanding of your existing tools. For that, the best way, IMHO, is for you to try and start to use Visual Studio as Microsoft intended and then once you can build a simple project in the IDE you can move to building it using your preferred make system but do so with an understanding of how the IDE is using its make system to set things up for that build (which WILL work).
So, for example, for part 1 of your question you want to create a simple static library project and a simple dll project and look at the linker options tabs. Jump to the 'Command line' view and you'll see that a DLL uses the /OUT linker option to set the name and location of the dll file and the /LIB linker option to set the name and location of the import library. With a static library only the /OUT option is used and it indicates the name of the static lib. It's true that if you're building a static lib and a DLL from the same source and you have both the /LIB for the dll set to MyCrossPlatformCode.lib and /OUT set to MyCrossPlatformCode.dll then you may have problems if you also build a static lib with an /OUT switch of MyCrossPlatformCode.lib... Simply don't do that; either build the static libs to a different output directory (which is what OpenSSL does), or, better (IMHO), mangle the names somewhat so that you have MyCrossPlatformCode.lib/.dll and MyCrossPlatformCode_static.lib (which is what STLPort does).
Note that you might also want to mangle in (or account for) building with different versions of the Microsoft tool chain (so you might end up with stlport_vc8_x64d_static.5.1, perhaps).
An alternative approach, if you really can't face the thought of understanding your toolset, is that you could take a look at some of the popular open source systems that build quite fine on Windows and Unix systems; OpenSSL and STLPort for a start, perhaps.
I have downloaded QT SDK LGLP (Creator + libraries) 4.6 and I am having problems compiling projects. After install I have added C:\Qt\2010.02\qt;C:\Qt\2010.02\qt\bin to PATH and added QTDIR env varaible containing C:\Qt\2010.02\qt, the I run "configure -platform win32-g++" to compile it. Everything went good.
I the tried to use QT Creator to create and compile a project.
The problem is everytime I try to compile I get the following error message:
No valid Qt version set. Set one in Tools/Options
Error while building project GUITest
When executing build step 'QMake'
Canceled build.
When I go to Tools/Options the manual version is set to v4.6.2, Location c:\qt\2010.02\qt\bin\qmake.exe. The auto detected version is set to even though I have added the dirs in Path. Is there something I am doing wrong here? Has anyone encountered this problem in Vista.
I have been working on this for 2 days, change configurations, reinstalled etc...
The QtDir value is compiled into the
qmake-binary. You can only change this
by recompiling qmake and passing on a
different value to qt-configure (I'm
not sure which setting or variable is
passed on to qmake) When using
precompiled, downloaded binaries,
you'll have to keep the QtDir at
c:\Qt\4.6.2
EDIT:
What I said was incorrect. The locations of qmake, moc,... are located in the file:
<Qt>/4.x.x/.qmake.cache
Try uninstalling/reinstalling qt creator
But i highly suspect you didnt compile qt properly as this problem seems really odd. I had alot of problems compiling so i know myself from the past mistakes.
Make sure you carefully reread install instructions for your environment, also if you have visual studio you need to follow procedure to install it in compliance with it. Same if you use another c compiler
If nothing goes right, the easiest way to install qt imo is directy from their git hub, chec installin qt from git, on their git site there is wiki that explains how to do it
its really easy and after that all you need to do is add the qt to creator
Hey, it QT emulators have lot of problems in vista, i have tried several times,it didnt work for me.. it works well with windows XP. though ill tell you in brief what you need to do
1)install latest perl
2)install carbide c++ editor
3)install Qt SDK
4)install s60 or N97 emulators
make sure that except perl all the items which are mentioned above will be in same drive,and also
make sure that folder names which you give while installation should not have spaces at all..
i.e suppose if you are going to place any of the above items in a folder whose name is having spaces it will not work.
if you have any doubts feel free to ask.
I'm doing some development right now using dsPICs and I'm not exactly in love with MPLAB. I'm actually using Visual Studio with a makefile project. Currently I'm using SCons, which seems to work fairly well, after finding a helpful guide to setting up to use an alternate compiler. Still, I can't help but wonder, is there a better build system for this? And also, is there a better way to make Scons do this?
Just use vim, makefiles and call the MPLAB command line compiler yourself.
There are quite a few build systems that you can use:
Buildroot http://www.buildroot.net/
Buildroot-ng http://wiki.openwrt.org/
crosstool-NG http://www.crosstool-ng.org/
PTXdist http://www.ptxdist.org/
OpenEmbedded http://www.openembedded.org/
OE-lite http://oe-lite.org/
muddle https://code.google.com/p/muddle/
Poky http://pokylinux.org/
OpenBricks http://www.openbricks.org/
Yocto Project http://www.yoctoproject.org/
Scratchbox http://www.scratchbox.org/
Cross Linux From Scratch http://www.cross-lfs.org/
Aboriginal Linux http://landley.net/aboriginal/
The very simplest way to do embedded development is to use your favourite code editor for writing the code, then switch to the compiler's IDE to build and download the code to the processor.
Obviously, the code editor and the compiler IDE may be the same thing, which is even simpler!