Fix #1441, patch build for old RTEMS

[jphickey]

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I signed and emailed the appropriate Contributor License Agreement to GSFC-SoftwareRelease@mail.nasa.gov and copied cfs-program@lists.nasa.gov.

Describe the contribution
Ignore the call to pthread_setname_np() on RTEMS 4.x. This becomes a no-op, and OSAL is able to build again.

Fixes #1441

Testing performed
Build on RTEMS 4.11

Expected behavior changes
Build succeeds

System(s) tested on
Debian with RTEMS 4.11 toolchain

Contributor Info - All information REQUIRED for consideration of pull request
Joseph Hickey, Vantage Systems, Inc.

[skliper]

Carrying RTEMS 4.11 seems like a fair amount of overhead for just int/long testing, especially if it's really the long term solution. 64 bit linux int and long are different sizes and catches if you don't have the correct print format. If that isn't exactly the concern, what is it? This becomes even more challenging if we start to adopt more of the RTEMS POSIX implementation which arguably could reduce quite a bit of OSAL code. I'd think targeting modern OS's/HW systems would be a better expenditure of resources?

[skliper]

Is it uint32_t vs int that's getting missed? Seems like int vs long gets caught by 64-bit linux:

int_long.c:5:30: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'int' [-Wformat=]
    5 |    printf("Int = %u, Int = %lu, long = %u, long = %lu\n", (int)5, (int)5, (long)5, (long)5);
      |                            ~~^                                    ~~~~~~
      |                              |                                    |
      |                              long unsigned int                    int
      |                            %u
int_long.c:5:41: warning: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'long int' [-Wformat=]
    5 |    printf("Int = %u, Int = %lu, long = %u, long = %lu\n", (int)5, (int)5, (long)5, (long)5);
      |                                        ~^                                 ~~~~~~~
      |                                         |                                 |
      |                                         unsigned int                      long int
      |                                        %lu

[skliper]

Thoughts - the current test only does a build, but by including the OSAL and PSP it requires support for RTEMS 4.11 in those elements. What if the test was just to build everything except OSAL and PSP (cFE, apps)... no need to link it. Then we wouldn't be held back by supporting RTEMS 4.11 from the OSAL and PSP point of view, yet still catch issues with int not being the same size as int32_t (if that's the real issue)?

[skliper]

@jphickey @dzbaker - just confirmed you don't need to support RTEMS 4.11 from osal to use the RTEMS 4.11 compiler to build an app (I did DS) to confirm it reports errors for incorrect assumptions that int is the same size as int32_t. I recommend dropping support for RTEMS 4.11 in OSAL if testing the common code is the only reason we keep carrying it (just compile the common elements).