Wiring pi is defunct.

WiringPi certainly does work with Pi 4, I have used it myself on Pi 4. 

However, it is not maintained (the author doesn't wish to maintain it anymore), so it won't work with Pi 5 at all (unless someone adapts it, which the original author I think doesn't have an interest in pursuing). There is a list of alternatives (some are for Python, but there are some listed for C) here: https://raspberrypi.stackexchange.com/questions/117591/controlling-raspberry-pi-gpio-with-c-and-python

However, I've not tried any alternative personally on Pi 4. With C, I've only used WiringPi on Pi 4.

I suspect some people (those that need it for, say, a job and thus have the time - several days of effort to do it properly) are directly programming registers (i.e. do a mmap, followed by writing/reading the registers that are mapped) for the particular Pi they are using, and effectively creating their own API. I've had to do that myself on some platforms (e.g. BeagleBone Black), but it's a lot of effort to initially do, and to maintain. 

In summary, if it's only Pi 4 that interests you, and you wish to use C programming, then WiringPi should work. Otherwise, if you may eventually want Pi 5 support too, you'd need to choose a different library (e.g. pigpio, but there are various options at that link), which today may not work for Pi 5 but at least has a chance of being supported eventually, if it is actively being maintained currently, or create your own.

If you don't need fast GPIO, then there are other options (e.g. using /sys/class/gpio) but those are slower. Not every application will need speed, so that may be a possibility. 

Yet another possibility is to use SPI or I2C (e.g. SPI or I2C GPIO expander) and avoid the WiringPi and its alternatives altogether since you'd be using the normal Linux i2cdev or spidev API, which will always be supported (unless something better comes along one day).

WiringPi certainly does work with Pi 4, I have used it myself on Pi 4. 

However, it is not maintained (the author doesn't wish to maintain it anymore), so it won't work with Pi 5 at all (unless someone adapts it, which the original author I think doesn't have an interest in pursuing). There is a list of alternatives (some are for Python, but there are some listed for C) here: https://raspberrypi.stackexchange.com/questions/117591/controlling-raspberry-pi-gpio-with-c-and-python

However, I've not tried any alternative personally on Pi 4. With C, I've only used WiringPi on Pi 4.

I suspect some people (those that need it for, say, a job and thus have the time - several days of effort to do it properly) are directly programming registers (i.e. do a mmap, followed by writing/reading the registers that are mapped) for the particular Pi they are using, and effectively creating their own API. I've had to do that myself on some platforms (e.g. BeagleBone Black), but it's a lot of effort to initially do, and to maintain. 

In summary, if it's only Pi 4 that interests you, and you wish to use C programming, then WiringPi should work. Otherwise, if you may eventually want Pi 5 support too, you'd need to choose a different library (e.g. pigpio, but there are various options at that link), which today may not work for Pi 5 but at least has a chance of being supported eventually, if it is actively being maintained currently, or create your own.

If you don't need fast GPIO, then there are other options (e.g. using /sys/class/gpio) but those are slower. Not every application will need speed, so that may be a possibility. 

Yet another possibility is to use SPI or I2C (e.g. SPI or I2C GPIO expander) and avoid the WiringPi and its alternatives altogether since you'd be using the normal Linux i2cdev or spidev API, which will always be supported (unless something better comes along one day).

is that a 32bit or 64 bit version of the OS?
Im looking a pigpio, they do some weird things, with how it runs as a daemon.

I would also have suggested pigpio library as the one to use for most general needs. I did come across this link, which offers some other alternatives, e.g. sysfs, or if really up for it, using direct register access.

elinux.org/RPi_GPIO_Code_Samples

shabaz said:

there are other options (e.g. using /sys/class/gpio)

I use those, if I don't need fast IO. 

I suspect often people don't need the speed, but simply want DigitalIn/DigitalOut style API functions like a microcontroller's libraries may offer, or Arduino even, and probably they would not mind if the underlying implementation used /sys/class/gpio. 

Even if slower IO is fine, sometimes an OCD gets the better of me and makes me want to implement it using registers, but it's a lot of work!

As an exercise, I created a little C++ GPIO lib:  C++ gpio library for Raspberry Pi - Pt 1: Design and How To Use 

Here's yet another, more generic, C programming option for Linux, which looks to be quite active in development but is not found in that list. Have yet to test performance...

github.com/.../c-periphery

Nice find. Regarding your performance comment, I think for general I/O they have a wrapper around /sys/class/gpio, so it won't be super-fast, but most users just want a wrapper anyway, with a simple API, so it should still be fine for a lot of purposes.

I'm currently writing a direct register access API for a different board that I need to use, it's going to be basic because I don't wish to maintain something complex. but I wish SBC manufacturers had standardized on a way to make it simple for C/C++ developers to use fast access without having to delve into tech ref manuals, e.g. some C/C++ API framework and a config file that was tailored for the processor/SBC.  I wish raspberrypi.com had taken the initiative and come up with something like a framework that any SBC supplier could use to implement GPIO with the same underlying API calls. That way, people could modify apps to suit Pi 5, 6, etc or other manufacturer boards too.

A few things that would be useful for that would be the ability to write an API on top (such as DigitalIn/DigitalOut for those who want an Arduino-style API), plus the ability to map different identifiers. For instance, if a different SBC used completely different GPIO pins, it would be good if they could be mapped to Pi GPIO numbers (if people were porting code), or even map to physical pin numbers if desired. Lots of SBCs have a 40-way connector, but of course, the registers will be different.

Also, as well as C++, such a library would also be linkable to C code (since some legacy stuff might not compile as C++ without a load of errors).

All that, plus maintaining it, is quite some work for an individual, but a nice constrained, not-insurmountable uni project for a sponsored student for raspberrypi org etc.

I'm checking out the memmap register access on the RPi. To test if I can plug in another implementation in the little oo lib I made. Got sidetracked by LoRaWAN things