Project Home
Project Home
Trackers
Trackers
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
BroadcastCommunity.qnx.com will be offline from May 31 6:00pm until June 2 12:00AM for upcoming system upgrades. For more information please go to https://community.qnx.com/sf/discussion/do/listPosts/projects.bazaar/discussion.bazaar.topc28418
Forum Topic - New QNX C++ Project does not respect GCC_VERSION : (8 Items)
   
New QNX C++ Project does not respect GCC_VERSION  
Hello,

first of all, the new IDE 4.5 Tau is a great step forward! I could only suggest everyone to give it try immediately.

Today I've detected a minor difference to IDE 4.0. I've created a new QNX C++ Project. But the following build process 
fails because of selecting the old gcc 2.95. The reason is in the following line of the common.mk:

GCC_VERSION:=$($(call EXPRESSION,GCC_VERSION))

This does not extract the given gcc version:

GCC_VERSION=4.2.3


This is the line used for/from IDE 4.0:

GCC_VERSION:=$($(firstword $(foreach a, GCC_VERSION_$(CPUDIR) GCC_VERSION, \
			$(if $($(a)), $(a), ))))

and everything works as expected.

A bit annoying is that e.g. enabling the Debug version, this line is replaced by the old one, again.

Is this a known problem?

Bye
Christian
Re: New QNX C++ Project does not respect GCC_VERSION  
Interesting. I testd it on one of the latest builds. Works fine for me. 
So, let us to know about your build and which compilers are available on 
your host machine. I'd also appreciate console log and whatever you 
think can be helpful in this case.

My first thought: you used not the latest build of IDE and worked  
against QNX 6.3.2 (not 6.4).  There was a bug  when IDE did not 
recognize correctly QNX version  which caused it while building to apply 
wrong QNX_INTERNAL block.

Regards,

Alex.



Christian Leutloff wrote:
> Hello,
>
> first of all, the new IDE 4.5 Tau is a great step forward! I could only suggest everyone to give it try immediately.
>
> Today I've detected a minor difference to IDE 4.0. I've created a new QNX C++ Project. But the following build process
 fails because of selecting the old gcc 2.95. The reason is in the following line of the common.mk:
>
> GCC_VERSION:=$($(call EXPRESSION,GCC_VERSION))
>
> This does not extract the given gcc version:
>
> GCC_VERSION=4.2.3
>
>
> This is the line used for/from IDE 4.0:
>
> GCC_VERSION:=$($(firstword $(foreach a, GCC_VERSION_$(CPUDIR) GCC_VERSION, \
> 			$(if $($(a)), $(a), ))))
>
> and everything works as expected.
>
> A bit annoying is that e.g. enabling the Debug version, this line is replaced by the old one, again.
>
> Is this a known problem?
>
> Bye
> Christian
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post10462
>
>    

Re: New QNX C++ Project does not respect GCC_VERSION  
> Interesting. I testd it on one of the latest builds. Works fine for me. 
> So, let us to know about your build and which compilers are available on 
> your host machine. I'd also appreciate console log and whatever you 
> think can be helpful in this case.
> 
> My first thought: you used not the latest build of IDE and worked  
> against QNX 6.3.2 (not 6.4).  There was a bug  when IDE did not 
> recognize correctly QNX version  which caused it while building to apply 
> wrong QNX_INTERNAL block.

I'm using the latest public build:
eclipse.buildId=I20080516

You are right, I'm using QNX 6.3.0, SP3 with all the patches plus IDE 4.5, plus gcc 4.2.3 (incl. the binutils).

Is there a way to trick the IDE to determine the right version!?

> 
> Regards,
> 
> Alex.
> 
> 
> 
> Christian Leutloff wrote:
> > Hello,
> >
> > first of all, the new IDE 4.5 Tau is a great step forward! I could only 
> suggest everyone to give it try immediately.
> >
> > Today I've detected a minor difference to IDE 4.0. I've created a new QNX C+
> + Project. But the following build process fails because of selecting the old 
> gcc 2.95. The reason is in the following line of the common.mk:
> >
> > GCC_VERSION:=$($(call EXPRESSION,GCC_VERSION))
> >
> > This does not extract the given gcc version:
> >
> > GCC_VERSION=4.2.3
> >
> >
> > This is the line used for/from IDE 4.0:
> >
> > GCC_VERSION:=$($(firstword $(foreach a, GCC_VERSION_$(CPUDIR) GCC_VERSION, \
> 
> > 			$(if $($(a)), $(a), ))))
> >
> > and everything works as expected.
> >
> > A bit annoying is that e.g. enabling the Debug version, this line is 
> replaced by the old one, again.
> >
> > Is this a known problem?
> >
> > Bye
> > Christian
> >
> > _______________________________________________
> > General
> > http://community.qnx.com/sf/go/post10462
> >
> >    
> 


Re: New QNX C++ Project does not respect GCC_VERSION  
AFAIK, you should expect new build in a few days. It correctly 
discriminates version of QNX, I suppose. Stay tune

Alex


Christian Leutloff wrote:
>> Interesting. I testd it on one of the latest builds. Works fine for me.
>> So, let us to know about your build and which compilers are available on
>> your host machine. I'd also appreciate console log and whatever you
>> think can be helpful in this case.
>>
>> My first thought: you used not the latest build of IDE and worked
>> against QNX 6.3.2 (not 6.4).  There was a bug  when IDE did not
>> recognize correctly QNX version  which caused it while building to apply
>> wrong QNX_INTERNAL block.
>>      
>
> I'm using the latest public build:
> eclipse.buildId=I20080516
>
> You are right, I'm using QNX 6.3.0, SP3 with all the patches plus IDE 4.5, plus gcc 4.2.3 (incl. the binutils).
>
> Is there a way to trick the IDE to determine the right version!?
>
>    
>> Regards,
>>
>> Alex.
>>
>>
>>
>> Christian Leutloff wrote:
>>      
>>> Hello,
>>>
>>> first of all, the new IDE 4.5 Tau is a great step forward! I could only
>>>        
>> suggest everyone to give it try immediately.
>>      
>>> Today I've detected a minor difference to IDE 4.0. I've created a new QNX C+
>>>        
>> + Project. But the following build process fails because of selecting the old
>> gcc 2.95. The reason is in the following line of the common.mk:
>>      
>>> GCC_VERSION:=$($(call EXPRESSION,GCC_VERSION))
>>>
>>> This does not extract the given gcc version:
>>>
>>> GCC_VERSION=4.2.3
>>>
>>>
>>> This is the line used for/from IDE 4.0:
>>>
>>> GCC_VERSION:=$($(firstword $(foreach a, GCC_VERSION_$(CPUDIR) GCC_VERSION, \
>>>        
>>> 			$(if $($(a)), $(a), ))))
>>>
>>> and everything works as expected.
>>>
>>> A bit annoying is that e.g. enabling the Debug version, this line is
>>>        
>> replaced by the old one, again.
>>      
>>> Is this a known problem?
>>>
>>> Bye
>>> Christian
>>>
>>> _______________________________________________
>>> General
>>> http://community.qnx.com/sf/go/post10462
>>>
>>>
>>>        
>
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post10486
>
>    

Re: New QNX C++ Project does not respect GCC_VERSION  
The newer and the latest build are not removing my definition and let most of my definitions in place. Therefore I'm 
able to mix editing by hand and using the project properties. This is a huge step forward. Thanks.

But a minor issue remains:

Getting the GCC_VERSION from an included makefile is not supported, e.g. setting the following in defs.mk:

GCC_VERSION=4.2.3

and load this in common.mk:

include path/to/defs.mk

Then the build uses the gcc version 2.95.3 instead of the 4.2.3, the workaround is to define another variable in the 
defs.mk, e.g.:

USE_GCC_VERSION=4.2.3

and then put this additional line in each common.mk:

GCC_VERSION=$(USE_GCC_VERSION)

and the build uses 4.2.3 as it is desired.

The IDE 4.5 is a lot better than 4.0. However it can be improved further by supporting the inclusion of additional 
makefiles. At the moment the project properties dialog shows that the used gcc is the default one and not the version 4.
2.3. The version 4.2.3 is known to the IDE and it is selectable in the dialog.

I've created a tracker report:
http://community.qnx.com/sf/reporting/do/viewReport/projects.ide/reporting/report1008

Is this usefull?

Christian
Re: New QNX C++ Project does not respect GCC_VERSION  
argh, okay, it is a *report* for trackers - I wish could edit my last posting ...
Re: New QNX C++ Project does not respect GCC_VERSION  
There are some macros that could be overridden. But this is not a 
limitation, particularly for GCC_VERSION. This one can be defined
     - in common.mk manually or using project properties dialog from IDE.
     - in the file you included into common.mk if you do not have this 
setting in common.mk.
The collision can occur just in one case: if you have this macro 
definition in included make file and late other definition in common.mk. 
The last one could appear there if you either did it manually or 
selected in  project properties dialog non-default version of compiler.

Regards,

Alex.

On 07/10/2008 5:46 AM, Christian Leutloff wrote:
> argh, okay, it is a *report* for trackers - I wish could edit my last posting ...
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post14562
>
>    

Re: New QNX C++ Project does not respect GCC_VERSION  
I have retried it with the latest IDE (eclipse.buildId=I20080915).

The build does not honor the definition in the included makefile.

This is the output on the Console:

C:/programme/QNX630/host/win32/x86/usr/bin/qcc -V2.95.3,gcc_ntox86 

<---- common.mk begin  --->
# This is an automatically generated record.
# The area between QNX Internal Start and QNX Internal End is controlled by
# the QNX IDE properties.

XI_MKFILES_ROOT=$(CURDIR)/../../../../tools/mk
ifndef QCONFIG
QCONFIG=qconfig.mk
endif
include $(QCONFIG)

ifndef QNX_INTERNAL
QNX_INTERNAL=$(PROJECT_ROOT)/.qnx_internal.mk
endif

include $(XI_MKFILES_ROOT)/xidefs.mk

#===== USEFILE - the file containing the usage message for the application. 
USEFILE=

include $(MKFILES_ROOT)/qmacros.mk
include $(QNX_INTERNAL)
include $(MKFILES_ROOT)/qtargets.mk
OPTIMIZE_TYPE=$(OPTIMIZE_TYPE_$(filter g, $(VARIANTS)))
OPTIMIZE_TYPE_g=none
<---- common.mk end --->

<---- xidefs.mk --->
GCC_VERSION=4.2.3
<---- xidefs.mk --->

Any ideas where the problem is?