On 21/12/2021 16.42, Rasmus Villemoes wrote:
> Hi
>
> While trying to upgrade our vxworks 5.5 compiler to gcc12, I've hit a
> problem when loading the libstdc++ module on target. It manifests as
>
> [00] tShell memPartFree: invalid block 8bf72c in partition 9605dc.
> [00] tShell m
Hi
While trying to upgrade our vxworks 5.5 compiler to gcc12, I've hit a
problem when loading the libstdc++ module on target. It manifests as
[00] tShell memPartFree: invalid block 8bf72c in partition 9605dc.
[00] tShell memPartFree: invalid block 8bf38c in partition 9605dc.
[00]
On 10/12/2021 19.24, Olivier Hainque wrote:
> For the toolchains we build, this is achieved with a few
> configure options like:
>
> --with-sysroot
> --with-build-sysroot=${WIND_BASE}/target
So forward-porting our private patches up until
7bf710b5116 - libstdc++: Add support for '?' in link
On 17/12/2021 15.12, Olivier Hainque wrote:
> Hi Rasmus
>
>> On 17 Dec 2021, at 13:49, Rasmus Villemoes
>> wrote:
>
>> I'm not sure what to do. But this patch will definitely break our build
>> - primarily because we've done a private workaround.
>
> I don't think we can reasonably cope with p
On 17/12/2021 13.14, Olivier Hainque wrote:
> Hello,
>
> yvals.h on VxWorks expects the toolchain to provide its own
> version of the header, which we don't do.
>
> The attached patch adds a fixincludes hack to arrange to fallback
> on the common system definitions instead.
>
> We were able to g
On 17/12/2021 13.10, Olivier Hainque wrote:
> Hello,
>
> The attached patch adds a fixincludes add for VxWorks
> to add missing FP_ constant definition to math.h, intended
> for old versions of the kernel math.h header.
Don't you also need to add an fpclassify() macro? There's a
checking for ISO
On 17/12/2021 13.01, Olivier Hainque wrote:
> Hello,
>
> The attach patch adds a fixincludes "hack" for VxWorks
> to expose a more flexible (varargs) function prototype for 'open',
> able to accept calls with 2 or 3 arguments as we observe
> during libraries builds for powerpc vxworks 6.9.
>
> We
On 10/12/2021 16.06, Olivier Hainque wrote:
> Hello,
>
> The attached patch for libstdc++ / VxWorks helps building
> the library for old versions of the OS, as witnessed with
> VxWorks 6.9 in particular.
>
> It explicitly requests C99 features from old system headers,
> on which libstc++ relies s
On 10/12/2021 15.20, Olivier Hainque wrote:
> Hi again Rasmus,
>
>> On 1 Nov 2021, at 10:34, Rasmus Villemoes wrote:
>>
>> When the translation unit itself creates pointers to the ctors/dtors
>> in a specific section handled by the linker (whether .init_array or
>> .ctors.*), there's no reason fo
On 01/12/2021 14.17, Richard Biener wrote:
> On Wed, Dec 1, 2021 at 12:08 PM Rasmus Villemoes
> wrote:
>>
>> The transposition nolto -> notlo is confusing and it makes the long
>> name even harder to read than it already is - I kept reading it as
>> "not lo" until I realized it was a simply typo.
On 05/11/2021 16.12, Olivier Hainque wrote:
>
>
>> On 5 Nov 2021, at 15:12, Rasmus Villemoes wrote:
> We happen to also have a few fixincludes hunks around. Some of
> them have been there for years now and I thought would be nice to
> propagate at some point.
>
> Do you use it?
Sort of, kind
On 05/11/2021 15.08, Olivier Hainque wrote:
>
>
>> On 5 Nov 2021, at 09:48, Rasmus Villemoes wrote:
>> Applied to master and pushed - hope I've done it right.
>
> AFAICS, yes.
>
>> How about the gcc-11 branch, can it be applied there as well,
>
> Yes, I think so. The builds you do used to wor
On 05/11/2021 09.08, Olivier Hainque wrote:
> Hi Rasmus,
>
>> On 3 Nov 2021, at 14:18, Rasmus Villemoes wrote:
>>
>> The macro TARGET_VXWORKS7 is always defined (see vxworks-dummy.h).
>> Thus we need to test its value, not its definedness.
>>
>> Fixes aca124df (define NO_DOT_IN_LABEL only in vxwo
13 matches
Mail list logo
