Naming Standards about ppc-vxworks-binutils HOT 4 OPEN

I also plan on testing the package I built from debian's binutils source package using the TARGET environment variable on a robot soon. The only real difference I can see in the configuration is that internalization will be enabled (no --disable-nls).

If there is no way ever on any machine that internalization would work with powerpc-wrs-vxworks, then we can always contribute a fix back to debian's binutils package. That way, we would be following naming schemes, and we could entirely deprecate the custom binutils package.

We would, however, have to update the dependencies on all the other packages to follow the standard naming scheme, but that shouldn't be THAT hard.

Note that I haven't even taking a look at what building GCC out of the gcc-4.8 source package would be like. I'm imagining that the custom package would probably be easier in that instance.

from ppc-vxworks-binutils.

I did this specifically to use a non-standard name. I didn't want this package and an official package to have a name conflict.

The reasoning behind not using the standard GCC repo is because I was never able to get one to work (between the necessary configure flags and everything else...). And I didn't want to use a non-standard gcc but the standard binutils - for some reason it felt wrong.

In a future version, it's easy enough to change back to an official build with some hacking the debian/control file.

Just remember to pass the -e option whenever use environment variables to debuild. You can see examples in debmake.

from ppc-vxworks-binutils.

So do you think it's better to use the standard names? I'm not sure in this case. I might also try a build with the source package. It'll take a while to figure out how to get all the configure flags right, so this is a future target.

Also, as a side note so I don't forget, I'm thinking of updating the target CFLAGS in the GCC compilation.

from ppc-vxworks-binutils.

Well, I think that in the case of the binutils, the standard name could be used because it really doesn't have anything specific to the cRIO in the configuration flags.

Any reason you didn't want to use the standard binutils with a custom GCC? I think it would be advantageous to keep as much of this as clean as possible.

Looking through the debian/control file for the default binutils, it seems that the only flag missing in the standard version that the custom one has is the --disable-nls. From what I've read, I think that we SHOULD be ok, but I won't have time to test the binaries on a real cRIO until tomorrow, when I go back out to our build space.

from ppc-vxworks-binutils.