Pull requests

#2 Merged

Added Patches

  1. rbmj

I needed these patches to make libstdc++ compile. I guessed that adding the intmax_t and int_leastN_t and friends to stdint.h is better than including gstdint.h, as gstdint.h is dynamically produced (so it should adapt) and only part of gcc AFAIK.

I also needed to change around some includes as for some reason gccdist doesn't keep track of its own header files moving around.

  • Learn about pull requests

Comments (8)

  1. rbmj author

    Also, at the end, shouldn't there be a line at the end that adds an echo "export WIND_BASE=..." >> /etc/profile? Or is WIND_BASE only needed when compiling gcc (I know I got errors if that variable wasn't present)

    1. Cody Schafer repo owner

      On WIND_BASE: it is only needed when building. GCC's configure script copies what it needs into PREFIX.

      On stdint: I think using gstdint.h in libstdc++ is the right thing to do as gcc is supposed to build on platforms with broken stdints. That said, the vxworks c library needs significant cleanup, and adding proper (ie: standard) stdint support wouldn't be a bad idea. The only concern I have with using gstdint.h is whether it is properly installed by GCC (if the header in question needs to be reparsed at some point, for example: if someone disables precompiled headers).

      On the "write(...)" fixup with regards to const: I see no need to have this conditional on using c++, having const there helps C programmers too.

      On the additions to vxTypes.h (int_least*_t, et c.): These belong in stdint.h, why not put them there? Also: is the fastest 16 minimally 16bit type actually int16_t? (ie: int_fast16_t == int16_t? ).

      On basic_file.patch / ioctl signature: posix specs "int ioctl(int, int, ...)", but the powerpc calling convention means I can't change it to that. :( . Still, using "void *" as the type of the third argument might be a better choice (so that exsisting code doesn't break). Objections?

      On gcc-4.6.3-vxworks-libstdcxx.patch: looks like this is for the trunk (I've got the same thing locally). Just glanced at 4.6.3's configure and don't see that line (unless I'm not seeing something...).

      On the various wrn/corip/* includes: I guess this could be better than getting rid of the include entirely (not too happy with it, but I'll add it). Anything that would help me feel better about this?

      Honestly, It might be a good idea to have a repo with a set of fixed up libc headers for vxworks, given the amount of tweaking needed.

      1. rbmj author

        I think it'd be a good idea to have a repo for libc fixes. The fact that they shipped code that has non-existant includes amazes me. However, a quick glance at vxWorks.h scares me:

         * Copyright (c) 1984-2005 Wind River Systems, Inc.
         * The right to copy, distribute or otherwise make use of this software
         * may be licensed only pursuant to the terms of an applicable Wind River
         * license agreement. No license to Wind River intellectual property rights
         * is granted herein. All rights not licensed by Wind River are reserved
         * by Wind River.

        And concerning gcc-4.6.3-vxworks-libstdcxx.patch: I've been grabbing patches from many different areas (including the upstream of your fork) and I didn't keep good track of what patches I had applied. That's my bad.

        On basic_file.patch: I wish we could change it to follow posix convention, but changing it to void* should work. That'd be fine with me, and probably a better fix. The only issue I see with that is if theoretically one was compiling ioctl.c (or whatever they call it) the C compiler would get angry at them. But that shouldn't be an issue AFAICS.

        You're right, int_fast16_t should probably just be int. I'm not familiar with powerpc assembly, but the same argument can be made as well for int_fast8_t. And the should be in stdint.h but since their stdint.h doesn't do much beyond include vxTypes.h, I put everything there to try and be consistent with what they provided (though I guess being consistent with bad code isn't ideal or even a good thing :/).

        Maybe we could add a symlink instead of wrn/coreip/*? That way we keep some semblance of POSIX compliance.

        EDIT: And no problem. Glad to help :)

        1. rbmj author

          OK, just looked at the ucpp config Makefile, and maybe the problem is that we need to add $WIND_BASE/target/h/wrn/coreip to the search path. Maybe the libc requires that these be in the include path. The other option is to do a comprehensive edit of the libc headers and make everything nicer... this seems like a better option but I'm not sure of the legality.

      2. rbmj author

        Yay Necromancy... Anyway, I've been working on getting stuff accepted upstream, so hopefully most of the changes here will be incorporated into 4.8. [1] is approved, but not yet committed, and handles all of the patches to the WRS headers. [2] is also approved, but not yet committed, and allows one to force a build of libstdc++-v3 with --enable-libstdc++-v3 passed to configure. A fix for the first gcov issue (obvious) is at [3]. A fix for the second gcov issue (approved, not committed) is at [4]. With those things done correctly, a complete build works.

        With the wrn/coreip/* issues, my solution was to put everything under sys-include and then symlink include to sys-include/wrn/coreip. Not a pretty solution, but a functional one.

        I say this now because I don't know if I'm going to get a chance to work on this for a long time, so if somebody else is trying to get everything to play nice those patches and easy links to the discussion on GCC's mailing lists are out there.

        [1]: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00382.html [2]: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01525.html [3]: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01508.html [4]: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01548.html