[solved] compiler not "seeing" file in new path
-
wrote on 4 May 2011, 06:12 last edited by
The long signed int shows as 4 bytes. I can't use unsigned, or if I did, it would be more trouble than it's worth.
-
wrote on 4 May 2011, 06:18 last edited by
Just for curiosity, what OS and compiler are you using?
-
wrote on 4 May 2011, 06:22 last edited by
Running Mac OS and GNU compiler (relatively recent version).
I do need something that will port over to Windows, so I want the least-involved solution possible.
-
wrote on 4 May 2011, 17:29 last edited by
Tobias: that's a good point, and I may go that route.
Of course, the presenting issue of why Creator isn't following the path in my shell $PATH variable is still a mystery...
-
wrote on 4 May 2011, 18:42 last edited by
The definition for 64 bit int is "long long" or "long long int" on 32 bit OS.
@#ifdef UNIX32
/**- \typedef long long Int64
- \brief Defines an alias representing int 64.
/
typedef long long Int64;
/* - \typedef unsigned long long Uint64
- \brief Defines an alias representing uint 64.
/
typedef unsigned long long Uint64;
#endif
#if defined(UNIX64)
/* - \typedef long Int64
- \brief Defines an alias representing int 64.
/
typedef long Int64;
/* - \typedef unsigned long Uint64
- \brief Defines an alias representing uint 64.
/
typedef unsigned long Uint64;
#endif
#ifdef WIN32
/* - \typedef long long Int64
- \brief Defines an alias representing int 64.
/
typedef long long Int64;
/* - \typedef unsigned long long Uint64
- \brief Defines an alias representing uint 64.
*/
typedef unsigned long long Uint64;
#endif
@
I guess on a Mac it should work similar, but I do not have the experience.
-
wrote on 4 May 2011, 22:00 last edited by
mzimmer, regarding your include problem, try:
@
#include <tr1/cstdint>
@This works for me (on a Mac). cstdint is used in conjunction with boost/C++ TR1 standard, and is not in the standard include path, but in a tr1 subdirectory.
If you want to be portable, I would go with the Qt defined qintXXX types.
-
wrote on 4 May 2011, 22:01 last edited by
Thanks, Volker.
Am I wrong in believing that Creator picks up the environment variables from my shell?
-
wrote on 4 May 2011, 22:18 last edited by
If you just change the PATH variable in the shell (terminal), then you must start creator via open:
@
open /Applications/Qt\ Creator.app
@If you start it via the Finder or with Spotlight search, it will not see this change.
-
wrote on 4 May 2011, 22:22 last edited by
Oh.
Oops.
Does Creator maintain its own PATH variable?
BTW: the tr1/ worked...thanks.
-
wrote on 4 May 2011, 22:31 last edited by
No, that's a matter of OS X/Finder/launchd and works this way for every application which is started this way.
If you change the PATH in a terminal, it is only valid in this very terminal/shell and the processes started from that shell. It's even not visible in other terminal windows or even tabs.
But you can always add your own extensions to the environment in Creator in the build and run settings.
-
wrote on 4 May 2011, 23:42 last edited by
OK, thanks, Volker.
13/14