cd /home/Development/AMI_MDC_Dev_ Branch/Arm/MMP &&
/home/cmake-2.6.4-Linux-i386/bin/cmake -E cmake_depends "Unix Makefiles"
/home/Development/AMI_MDC_Dev_Branch/Arm/MMP
/home/Development/AMI_MDC_Dev_Branch/Arm/MMP
/home/Development/AMI_MDC_Dev_Branch/Arm/MMP
/home/Development/AMI_MDC_Dev_Branch/Ar
The fixup bundle function _should_ be taking care of any dylib or
framework that is linked to your application. If the function is NOT
doing this then either we need better instructions, updated
instructions or the function has been mis-used. I am betting a little
bit of all of that.
I use the fi
Here is the verbose output.
remember, this only happens when I invoke make from eclipse. when I invoke
make from the shell, everything is fine.
thanks for any insight
Build of configuration Linux GCC for project mdc
make appmonitor VERBOSE=1
/home/cmake-2.6.4-Linux-i386/bin/cmak
Hi Arnaud,
I am trying to make a stand alone bundle OS X application using
CMake. My application is based on Qt4.5.
I have been following the following wiki page (with QtTest example):
http://www.cmake.org/Wiki/BuildingOSXApplications
This bundle application works perfectly on a machine wher
Hi all,
I am trying to make a stand alone bundle OS X application using CMake.
My application is based on Qt4.5.
I have been following the following wiki page (with QtTest example):
http://www.cmake.org/Wiki/BuildingOSXApplications
This bundle application works perfectly on a machine where Qt
On Aug 17, 2009, at 2:16 PM, Michael Wild wrote:
On 17. Aug, 2009, at 18:40, Michael Jackson wrote:
On Aug 17, 2009, at 12:30 PM, ML wrote:
Hi Mike,
The double __LP64__ is making sure it (__LP64__) is both DEFINED
and TRUE.
# if defined ((__APPLE__)) && defined(__LP64__) && __LP64__
On 17. Aug, 2009, at 18:40, Michael Jackson wrote:
On Aug 17, 2009, at 12:30 PM, ML wrote:
Hi Mike,
The double __LP64__ is making sure it (__LP64__) is both DEFINED
and TRUE.
# if defined ((__APPLE__)) && defined(__LP64__) && __LP64__
typedef CIconHandle OSColorIcon; // Mac CIcon
#els
Kenneth Chang wrote:
thx, yes, it's 64-bit linux.
So, Brad King is the person who is the expert in the elf linking in
CMake, and he is on vacation right now.
I did find this comment, which describes pretty much what is going on:
From cmComputeLinkInformation.cxx:
---
On Aug 17, 2009, at 12:30 PM, ML wrote:
Hi Mike,
The double __LP64__ is making sure it (__LP64__) is both DEFINED
and TRUE.
# if defined ((__APPLE__)) && defined(__LP64__) && __LP64__
typedef CIconHandle OSColorIcon; // Mac CIcon
#else
To to help me fine tune a bit..
Wouldn't (__APPLE
On Aug 17, 2009, at 12:30 PM, ML wrote:
Hi Mike,
The double __LP64__ is making sure it (__LP64__) is both DEFINED
and TRUE.
# if defined ((__APPLE__)) && defined(__LP64__) && __LP64__
typedef CIconHandle OSColorIcon; // Mac CIcon
#else
To to help me fine tune a bit..
Wouldn't (__APPLE_
Hi Mike,
The double __LP64__ is making sure it (__LP64__) is both DEFINED and
TRUE.
# if defined ((__APPLE__)) && defined(__LP64__) && __LP64__
typedef CIconHandle OSColorIcon; // Mac CIcon
#else
To to help me fine tune a bit..
Wouldn't (__APPLE__) be automatically defined if I am compil
The double __LP64__ is making sure it (__LP64__) is both DEFINED and
TRUE.
# if defined ((__APPLE__)) && defined(__LP64__) && __LP64__
typedef CIconHandle OSColorIcon; // Mac CIcon
#else
#endif
_
Mike Jackson mike.jack
Hi Sean,
I am running into some issues with some Carbon stuff that is not
avail
under 64-bit, but is for 32-but.
May I suggest you start by getting your stuff working in 32 bit first.
With all the old Carbon stuff you use, 64 bit support will be more
work. And as you're apparently changing
Kenneth Chang wrote:
Hi Bill,
I tried the same experiment with a boost .so and it worked. What's
interesting is that I can link with thostmduserapi.so if I do it
manually or just renamed it, and the application works, so it looks like
the file is a valid object. gcc/c++ doesn't complain abo
On 8/17/09 7:41 AM, ML said:
>I am running into some issues with some Carbon stuff that is not avail
>under 64-bit, but is for 32-but.
May I suggest you start by getting your stuff working in 32 bit first.
With all the old Carbon stuff you use, 64 bit support will be more
work. And as you're
# if defined ((__APPLE__)) && defined(__LP64__) && __LP64__
// 64 bit headers/defines/typedefs here
#else
// 32 bit headers/defines/typedefs here
#endif
_
Mike Jackson mike.jack...@bluequartz.net
BlueQuartz Software
Hi Bill,
I tried the same experiment with a boost .so and it worked. What's
interesting is that I can link with thostmduserapi.so if I do it
manually or just renamed it, and the application works, so it looks like
the file is a valid object. gcc/c++ doesn't complain about a bad object
eithe
Hi All,
I am running into some issues with some Carbon stuff that is not avail
under 64-bit, but is for 32-but.
Items like:
framework/CP_Types.h(304): error: identifier "CIconHandle" is undefined
typedef CIconHandle OSColorIcon;
// Mac
Hi Sean,
It would seem to me that
#if TARGET_OS_MAC
#endif
is not getting executed in my code.
I have:
#if TARGET_OS_MAC
typedef unsigned char
UInt8;
typedef signed char
S
On 8/16/09 2:27 PM, ML said:
>I am continuing my quest moving from XCode to CMake/Make
>
>This may be a Make specific question though.
>
>It would seem to me that
>
>#if TARGET_OS_MAC
>
>#endif
>
>is not getting executed in my code.
>
>I have:
>
>#if TARGET_OS_MAC
> typedef unsigned char
I
have a relatively simple cmake file that has generated a great big
Makefile (and associated CMake files) that compiles my project just
fine when I invoke it from the bash shell, simply by typing 'make'.
When I configure eclipse to do the same thing (simply calling make in the same
directory)
21 matches
Mail list logo