Re: Alternate GCC Toolchain
 

I can't really sleep so I'm starting to do the binary searching. Do you have a cRIO with you now or no?

Re: Alternate GCC Toolchain
 

No it's at my school... Was thinking about taking the test bed home but that didn't happen...

Edit: I'm not sure if this's relevant, I just though of something else. Previous attempts also yielded the "_start" symbol error. However, they also gave a "relocation value does not fit within 24 bits" error, while this attempt did not.

Re: Alternate GCC Toolchain
 

Well its good to know that something got fixed. I asked my mentors to take a cRIO with me, but they weren't too keen on the idea either. How old of an attempt are we talking about here?

Re: Alternate GCC Toolchain
 

Both results from the old post and this post gave me these errors. I'm assuming it was an error on my part...

Re: Alternate GCC Toolchain
 

I can actually do the binary search without a cRIO, as (once I know what to look for) I can have a script determine if it holds a reference to _start.

I'm working on getting a setup to compile a patched old compiler now.

Edit: Compiling last march's gcc with the patches. Let's see if this one works.

Re: Alternate GCC Toolchain
 

OK, I can confirm that it's a flag issue, not a compiler issue. Now just to determine which one...

Re: Alternate GCC Toolchain
 

Alright, I've tested the fix of the "_start" symbol error, and it appears that everything is now working. Yay! I've also included netconsole output as proof.

Edit: I'd still like to resolve the errors I encountered during the VM installation, detailed in this post.

Re: Alternate GCC Toolchain
 

OK, so after some testing it looks like it's a problem with the link script. I'll investigate further.

Also, the new packages do not require you to set WIND_BASE as they install a script to set it in /etc/profile.d. As long as your /etc/profile will source everything in /etc/profile.d (which is the default in modern debian and I think thus modern ubuntu), don't bother setting that. The issue is that the toolchain file looks in the environment for WIND_BASE and goes off of that, which for this toolchain MUST be /usr/powerpc-wrs-vxworks/wind_base.

Re: Alternate GCC Toolchain
 

Could it be a problem with the compiler configuration as well? IIRC from a while back, libmudflap had a reference to _start. Was a --disable flag maybe forgotten when configuring the compiler?

Just an idea. I don't have access to a cRIO just this second so I can't test much other than just looking at objdumps.

Re: Alternate GCC Toolchain
 

I must have originally forgotten to use the link script when I checked things, as the script has ENTRY(_start) in it. Either that, or an update to ld where originally it would ignore this directive if it couldn't find the symbol but now adds it in as an unresolved symbol. I don't know which.

I'm modifying the wrs-headers-installer script to make a new ld script. Unfortunately the update is going to require you to re-download gccdist and everything as I don't have time to do the upgrade "correctly". Therefore, I won't change the version, and I'll give you a script that will perform the update.

Re: Alternate GCC Toolchain
 

OK, so at the original download link I've updated the buildscripts and wrs-headers-installer packages. Since they're still considered beta I'm not upgrading the versions, but if you install with dpkg it will still overwrite.

If you have the old wrs-headers-installer package, you do not need to update that package, but you do need to update the buildscripts package. You also need to run this:

Note that that needs to be run as root - I would use su (or sudo su), not sudo as sudo sometimes has issues with io redirection (in my experience).

Once you've run those commands, verify that /usr/powerpc-wrs-vxworks/share/ldscripts/dkm.ld exists and has content in it.

If you do this, that should fix the unresolved symbol error for _start.

Re: Alternate GCC Toolchain
 

FWIW, I've submitted the patch to the WPILib tracker. I'm not sure if it'll come to anything, but w/e.

Open source does not mean open development...

Thanks all for your help in debugging this! Hopefully this will fix things. A preliminary build of my team's code from last year works, and I can't find any of the usual suspect errors that I can catch by looking at the binaries with binutils.

Re: Alternate GCC Toolchain
 

It doesn't, as far as I can see... Updated both the buildscripts and wrs headers, removed the fix from my code, and then got a "_start symbol" error. I then attempted to run the code you posted, but that didn't solve it either...

Edit: I'm sorry, I started a new project and things worked just fine...

Re: Alternate GCC Toolchain
 

:D Awesome!

Re: Alternate GCC Toolchain
 

Things are working well here as well, though it seems that I'm unable to use any of the C++11 memory management features. It fails at compile time, saying that std::unique_ptr doesn't refer to a type. Aren't these supposed to work? If not, why? (Just curious).