Relocations R_PPC_TPREL16_LO and R_PPC_TPREL16_HA unsupported

[ghost]

I'm not sure if this is a wut thing or a devkitPPC thing, but in trying to port some code to wut I've encountered the following errors when creating the rpx file:

ERROR: Unsupported relocation type 72
ERROR: Unsupported relocation type 70
ERROR: fixRelocations failed.

I'm using the CMake toolchain like in the hello_world C++ CMake example. Is the issue above caused by something in my environment?

[ashquarky]

70 and 72 definitely don't seem like valid relocations - closest I can get is assuming those are hex 70 and 72, which gives R_PPC_EMB_RELST_LO and R_PPC_EMB_RELST_HA - both of which are actually unsupported in elf2rpl. Are you able to share the code you've been working on, some object files (like the .elf cmake generated), or anything else that causes the issue?
If gcc actually generates relst relocations, we'll have to look at adding a special case or translation (or even a hack in devkitPPC).

[ghost]

Sure! It's actually really easy to reproduce, you just need to compile something that includes and uses this library - specifically blockingconcurrentqueue.h.

For the sample above, I did have to provide a semaphore implementation. I made a basic wrapper around the Wii U OSSemaphore to achieve that (insert after line 245 of blockingconcurrentqueue.h):

#elif defined(PLATFORM_WIIU)
    //---------------------------------------------------------
    // Semaphore (POSIX, Linux)
    //---------------------------------------------------------
    class Semaphore
    {
    private:
      OSSemaphore m_sema;

      Semaphore(const Semaphore& other) MOODYCAMEL_DELETE_FUNCTION;
      Semaphore& operator=(const Semaphore& other) MOODYCAMEL_DELETE_FUNCTION;

    public:
      Semaphore(int initialCount = 0)
      {
        assert(initialCount >= 0);
        OSInitSemaphore(&m_sema, initialCount);
      }

      ~Semaphore()
      {
      }

      void wait()
      {
        OSWaitSemaphore(&m_sema);
      }

      bool try_wait()
      {
        // http://stackoverflow.com/questions/2013181/gdb-causes-sem-wait-to-fail-with-eintr-error
        int remainingAttempts = 100;
        int rc;
        do {
          rc = OSTryWaitSemaphore(&m_sema);
          remainingAttempts--;
        } while (rc <= 0 && remainingAttempts >= 0);

        return remainingAttempts > 0;
      }

      bool timed_wait(std::uint64_t usecs)
      {
        // FIXME: Wii U doesn't have a timed wait for semaphores?
        return try_wait();
      }

      void signal()
      {
        OSSignalSemaphore(&m_sema);
      }

      void signal(int count)
      {
        while (count-- > 0)
        {
          OSSignalSemaphore(&m_sema);
        }
      }
    };
#else

[Seng-Jik]

link to wiiu-sdl2 will reproduce this error.

[GaryOderNichts]

The title for this issue seems to be wrong.
According to wut-tools, 70 and 72 is R_PPC_TPREL16_LO and R_PPC_TPREL16_HA.
Those are for the Thread Local Storage ABI and not supported due to missing TLS support.

[Wohlstand]

On my end there are different errors happen:
R_PPC_PLTREL24 (18) and R_PPC_LOCAL24PC (23)

ERROR: Unsupported relocation type 18
ERROR: Unsupported relocation type 23
ERROR: fixRelocations failed.

And ye, I also trying to link the SDL2 thing. Anyway, in addition to that, I do have a large pile of other libraries that are built from the source. I attempted to disable the -fPIC on all of them, but seems that took no effect... 🤔

[GaryOderNichts]

On my end there are different errors happen: R_PPC_PLTREL24 (18) and R_PPC_LOCAL24PC (23)

ERROR: Unsupported relocation type 18
ERROR: Unsupported relocation type 23
ERROR: fixRelocations failed.

And ye, I also trying to link the SDL2 thing. Anyway, in addition to that, I do have a large pile of other libraries that are built from the source. I attempted to disable the -fPIC on all of them, but seems that took no effect... 🤔

These relocations are used for position-independent code and are unrelated to TLS and this issue.
It sounds like one of the libraries in your "pile of other libraries" is built using position-independent code. Try a minimal test case only using packages from the pacman repos and see if the issue persists.

[Wohlstand]

Ye, just now I found the last library where -fPIC was been enabled, and I disabled it, and thing got been built finally. Before that I tried one of exapmles from samples/ sub-directory of this repo, and it successfully built and linked.