Project Home
Project Home
Source Code
Source Code
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - 4.2.1 gcc instructions incomplete: (12 Items)
   
4.2.1 gcc instructions incomplete  
The instructions for intalling gcc 4.2.1 and binuntils 2.17 from 
<http://community.qnx.com/sf/wiki/do/viewPage/projects.toolchain/wiki/Downloads_gcc4.2Preview>;
do are incomplete -- at least for the purposes of building the kernel with 4.2.1

I'm told it's also necessary to checkout /tools/mkfiles and then direct make to use /tools/mkfiles with an incantation 
like: 

make -I/root/headsvn/tools/mkfiles MKFILES_ROOT=/root/sandbox/tools/mkfiles QCONFIG=/root/sandbox/tools/mkfiles/qconf-$
{SYSNAME}.mk $*

That makes the kernel compile for x86. But I'm told that a large number of additional patches are required' for other 
architectures. I'm told those patches are floating around in emails.  

If anyone has gotten 4.2.1 to work correctly for all architectures, could they post somewhere the complete least of 
patches, tweaks and magic needed to get a 4.2.1 sandbox to work? 

-ad. 

ps. This is a potential time saver for people. I know at least one member of my team has given up trying to setup a 
complie environment for 4.2.1. I managed to get x86 working but it cost me a couple of days before I figured out the 
instructions were incomplete.



-ad 
Re: 4.2.1 gcc instructions incomplete  
> The instructions for intalling gcc 4.2.1 and binuntils 2.17 from 
> <http://community.qnx.com/sf/wiki/do/viewPage/projects.toolchain/wiki/Downloads_gcc4.2Preview>;
> do are incomplete -- at least for the purposes of building the kernel with 4.2
> .1

If they're specific instructions for building the kernel, they should go on the coreos wiki. The mkfiles changes are 
only required for building the kernel because the LDBOOTSTRAP macro had an hardcoded path to libgcc.a.

Regards,

Ryan Mansfield
Re: 4.2.1 gcc instructions incomplete  
Btw, weve also found that objdump -S for a .g load no longer correctly intersperse the source lines into the assembler. 


Is that a tool-chain problem or a coreos problem?
Re: 4.2.1 gcc instructions incomplete  
On Wed, 2008-03-19 at 12:04 -0400, Attilla Danko wrote:
> Btw, weve also found that objdump -S for a .g load no longer correctly
> intersperse the source lines into the assembler. 

Works for me on a 6.4 self hosted.

Try nto<cpu>-objdump-2.17.  gcc 2 uses a different debugging info format
than gcc 4.

Re: 4.2.1 gcc instructions incomplete  
>Try nto<cpu>-objdump-2.17.  gcc 2 uses a different debugging info format
than gcc 4.

Thanks Sean. ntox86-objump-2.17 -S appears to be working correctly on my nto host. One person has reported it mixing the
 c-source and assembler incorrectly on a Linux host. However, we don't know if that's a binutils problem or one messed 
up sandbox. 
Re: 4.2.1 gcc instructions incomplete  
On Wed, 2008-03-19 at 15:57 -0400, Attilla Danko wrote:
> >Try nto<cpu>-objdump-2.17.  gcc 2 uses a different debugging info
> format 
> than gcc 4.
> 
> Thanks Sean. ntox86-objump-2.17 -S appears to be working correctly on
> my nto host.

It's such a thankless job to be in tools and help people, 'cause other
folks get thanked for the help we provide :-) :-) :-)

>  One person has reported it mixing the c-source and assembler
> incorrectly on a Linux host. However, we don't know if that's a
> binutils problem or one messed up sandbox.

Well, if that person can provide more details, then maybe we can help.

However, if the code is optimized, objdump could definitely have
difficulties being accurate in the mixing of C and assembler code.  And
that maybe what the person is observing.

Re: 4.2.1 gcc instructions incomplete  
> That makes the kernel compile for x86. But I'm told that a large number of 
> additional patches are required' for other architectures. I'm told those 
> patches are floating around in emails.  

The patches to the mkfiles and nto.link are checked into the svn. LDBOOTSTRAP and nto.link are specific to core os 
components. The new compiler exposed a hardcoded path and a incomplete linker script.
These problems are with coreos components and should be documented by the coreos team on the coreos wiki. There are 
other projects besides the kernel team that use the toolchain, and these is absolutely no requirement for those people 
to update their mkfiles and nto.link files to have a working toolchain.

> If anyone has gotten 4.2.1 to work correctly for all architectures, could they
>  post somewhere the complete least of patches, tweaks and magic needed to get 
> a 4.2.1 sandbox to work? 

This should be a question asked in the coreos forums. I don't think people will come looking in the toolchain forum for 
instructions on how to build the kernel. :)

>ps. This is a potential time saver for people. I know at least one member of 
> my team has given up trying to setup a complie environment for 4.2.1. I 
> managed to get x86 working but it cost me a couple of days before I figured 
> out the instructions were incomplete.

A couple of days? Wow! The instructions on how to build the kernel on the coreos wiki are definitely incomplete if not 
everyone on the kernel team is aware of how the kernel gets built.

Regards,

Ryan Mansfield 
Re: 4.2.1 gcc instructions incomplete  
C'mon guys let's all get along. :-)

Ryan is right that we should update the CoreOS wiki with the 'tweaks' that are needed.

However, the fix to qconf-*.mk for the libgcc.a is still missing the actual nto<cpu>-gcc-4.2.1 driver
util... :-)

Ryan Mansfield wrote:
>  > That makes the kernel compile for x86. But I'm told that a large 
> number of
>  > additional patches are required' for other architectures. I'm told those
>  > patches are floating around in emails. 
> 
> The patches to the mkfiles and nto.link are checked into the svn. 
> LDBOOTSTRAP and nto.link are specific to core os components. The new 
> compiler exposed a hardcoded path and a incomplete linker script.
> 
> These problems are with coreos components and should be documented by 
> the coreos team on the coreos wiki. There are other projects besides the 
> kernel team that use the toolchain, and these is absolutely no 
> requirement for those people to update their mkfiles and nto.link files 
> to have a working toolchain.
> 
>  > If anyone has gotten 4.2.1 to work correctly for all architectures, 
> could they
>  >  post somewhere the complete least of patches, tweaks and magic 
> needed to get
>  > a 4.2.1 sandbox to work?
> 
> This should be a question asked in the coreos forums. I don't think 
> people will come looking in the toolchain forum for instructions on how 
> to build the kernel. :)
> 
>  >ps. This is a potential time saver for people. I know at least one 
> member of
>  > my team has given up trying to setup a complie environment for 4.2.1. I
>  > managed to get x86 working but it cost me a couple of days before I 
> figured
>  > out the instructions were incomplete.
> 
> A couple of days? Wow! The instructions on how to build the kernel on 
> the coreos wiki are definitely incomplete if not everyone on the kernel 
> team is aware of how the kernel gets built.
> 
> Regards,
> 
> Ryan Mansfield
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post5957
> 

-- 
cburgess@qnx.com
Re: 4.2.1 gcc instructions incomplete  
> C'mon guys let's all get along. :-)
> 
> Ryan is right that we should update the CoreOS wiki with the 'tweaks' that are
>  needed.
> 
> However, the fix to qconf-*.mk for the libgcc.a is still missing the actual 
> nto<cpu>-gcc-4.2.1 driver
> util... :-)

Who is going to believe that it cost someone a 'couple of days' to see "ntox86-gcc-4.2.1 not found"??! 

The internal builds of the tools have had the driver for sometime. I'll check with the testers to see where they are at 
and we'll post the updated packages that include it.

I don't understand the expectation that toolchain documentation should include every 'tweak' for every dependency that 
every project/team has created on the old toolchain.

Regards,

Ryan Mansfield
Re: 4.2.1 gcc instructions incomplete  
On Wed, Mar 19, 2008 at 11:54:07AM -0400, Ryan Mansfield wrote:
> > That makes the kernel compile for x86. But I'm told that a large number of 
> > additional patches are required' for other architectures. I'm told those 
> > patches are floating around in emails.  
> 
> The patches to the mkfiles and nto.link are checked into the svn. LDBOOTSTRAP and nto.link are specific to core os 
components. The new compiler exposed a hardcoded path and a incomplete linker script.
> These problems are with coreos components and should be documented by the coreos team on the coreos wiki. There are 
other projects besides the kernel team that use the toolchain, and these is absolutely no requirement for those people 
to update their mkfiles and nto.link files to have a working toolchain.
> 
> > If anyone has gotten 4.2.1 to work correctly for all architectures, could they
> >  post somewhere the complete least of patches, tweaks and magic needed to get 
> > a 4.2.1 sandbox to work? 
> 
> This should be a question asked in the coreos forums. I don't think people will come looking in the toolchain forum 
for instructions on how to build the kernel. :)
> 
> >ps. This is a potential time saver for people. I know at least one member of 
> > my team has given up trying to setup a complie environment for 4.2.1. I 
> > managed to get x86 working but it cost me a couple of days before I figured 
> > out the instructions were incomplete.
> 
> A couple of days? Wow! The instructions on how to build the kernel on the coreos wiki are definitely incomplete if not
 everyone on the kernel team is aware of how the kernel gets built.
> 

I think this is indicative of a larger issue.  Not everyone
is an expert in all areas.  It would be nice if one could
check out and build the world starting with the tools which
are in turn used to build component 1, 2 ...

-seanb
Build the world (was 4.2.1 gcc instructions incomplete)  
> 
> I think this is indicative of a larger issue.  Not everyone
> is an expert in all areas.  It would be nice if one could
> check out and build the world starting with the tools which
> are in turn used to build component 1, 2 ...
> 

Any thoughts on this?  Would others find it useful?
Would now be a good time to think about this as
we're going through a 'build the world' phase?  Is
it worth a PR?

-seanb
RE: Build the world (was 4.2.1 gcc instructions incomplete)  
Hi Shawn,

Robert and I are working on the inter-project dependencies, CM and build
issues. One of the outcomes should be the clarification of the build
procedures for projects.

I suggest not to PR for now.

  Thanks

	- Fred

-----Original Message-----
From: Sean Boudreau [mailto:seanb@qnx.com] 
Sent: March 20, 2008 9:31 AM
To: general-toolchain
Subject: Build the world (was 4.2.1 gcc instructions incomplete)

> 
> I think this is indicative of a larger issue.  Not everyone
> is an expert in all areas.  It would be nice if one could
> check out and build the world starting with the tools which
> are in turn used to build component 1, 2 ...
> 

Any thoughts on this?  Would others find it useful?
Would now be a good time to think about this as
we're going through a 'build the world' phase?  Is
it worth a PR?

-seanb

_______________________________________________
General
http://community.qnx.com/sf/go/post5998