A little bit about portability

Recently, I 've been porting libc. I checked a lot of information on the Internet and found many libc, such as glic, uclibc, diet libc, newlib, etc. Except newlib, it is closely related to Linux and other systems, and the porting workload is too large.
Newlib can be used in many platforms and operating systems. during migration, you only need to provide a dozen functions that must be implemented by the operating system. Most of the information about newlib is related to cross-compilation. Therefore, I used many methods according to the information, and finally compiled newlib in cygwin, but it is used on the ARM platform. For the 386 platform, it has never been compiled successfully (remember that GCC cannot be compiled ). Later, I decided to directly transplant the source code of newlib, add appropriate compilation options, and directly compile the program. In case of problems, I realized the required functions. Finally, most of the functions are compiled successfully, but it seems that there are still some problems to use. For example, the print function cannot work normally. Only characters before line breaks are output. The problem could not be solved for a moment. I continued to port the libc of djgpp. Although I didn't like this library very much, it worked very well.

Speaking of this, I think of the GUI problem again. Myos has its own GUI, but its personal capabilities are limited after all. Although the myos gui works well
There are still a lot of work done, and only a few simple controls can not meet the needs of application development. Therefore, I often check some gui information. But like libc, most of the guis are used on the Linux platform. Some are based on X and some are based on the Linux framebuffer. The key is that they are closely related to the platform and have poor portability. There are several self-proclaimed cross-platform guis, such as wxwidget, fltk, and Fox. Next I came back and saw that a lot of things were rewritten on different platforms, such as wxwidgt, the control itself is the encapsulated system control, which obviously cannot be transplanted to myos (if myos has the control it needs, I won't want to transplant it, huh, huh ). There is also fltk, which is said to be highly portable. All the code is based on painting points and all the controls are drawn. Therefore, it is easy to port and add controls. This is exactly what I want. This is how myos's GUI is implemented. It has nothing to do with the platform. You only need to provide a BLT function. After downloading the code, we can see that the dependency on the system is still quite powerful. After one afternoon, I decided to give up.

Here, let's talk about my views. As a cross-platform libc and GUI, newlib and fltk provide good portability. However, there are still many shortcomings.
Taking newlib as an example, a dozen functions can be transplanted to the new platform, but many things need to be configured in order to be smooth under a new platform.
Compilation, although it provides an automatic configuration tool to help compile on supported platforms, but corresponding to the new platform, there will be no modifications to many configuration files.
In addition, a lot of define is used in the code, and some code is included according to the platform. I think both of these aspects compromise portability. My ideal
Portability is that you only need to provide the required functions and use any C compiler to compile the link directly. The configuration file and define are only suitable for definition.
Some features of the compiled library itself, such as whether the functions in the library can be reentrant, should not include platform-related things.

Over the past year, I spent a lot of time on these aspects. Although I didn't find my desired library for transplantation, I also learned a lot. Sometimes think about it
Yes. If it is transplanted, the upgrade and maintenance in the future will still be a problem, but this problem does not exist if you write it yourself. It seems that I want to remove the direct transplantation in the future
The idea of code should be improved by referring to others' code.