Have you looked at some other objects which talk to hardware?
E.g.
./axoloti-contrib/objects/tiar/HW/OLED128x64.axo
./axoloti-contrib/objects/tiar/HW/OLED128x64.axh
In general the issue is that the "object" gets called through its krate/srate code and that code can't hang around. ie- it can't wait for the hardware to do something. It needs to just produce/consume it's values/buffers and return- so the system can proceed in real time.
If you have something that's going to take some time (E.g. i2c access, polling an IR receiver, blinking an IR led) then the general approach is to start up another thread to handle it, and have that thread communicate with the krate code when it needs to.
What was normally "the arduino library" would be within that thread- e.g get the raw ir data and try to decode it per the type of frame you are interested in. When you have a valid frame you would send it to the krate code (shared variable, message passing, etc.) which would them make it available to other objects.
Adding to the fun is that the axoloti environment expects the object to be defined within the *.axo file(xml) which it then uses as input to code generate a tree of C++ objects (xpatch.cpp). It expects all of the code to be there (I don't think there is any facility with the patch building to compile and link stand-alone C/C++ files). It's possible to get it done, but it's different from the normal code development process.
In short - you need to do more than a simple port. You need to add some structure (thread to handle IR receive) and you need to change the way the arduino library shows up when the patch get's built (probably shove it all into xpatch.cpp via the include mechanism).
Other than that it seems pretty do-able.