I just answered your PM. I'm however not happy with my approach, because it is a hack.
Is there any kind of "legal", or remotely acceptable approach to adding missing functionality in the SDK?
My approach has been: 1. Build the project with make, which produces a libsignal.a. 2. Copy the signal.a to SDK:local/newlib/lib
Now you have to add a "-lsignal" whenever you want to use these signal functions. However, the official SDK signal.h, differs from mine. So either I override the SDK one, by adding an "-I/path/to/my/signal.h", or I simply replace the SDK one (oh nooooo!). The latter is really not an option. But this is somewhat cumbersome, and sometimes you can't easily change the build command line. Is it possible to somewhere in SDK, globally add extra include files, and standard link libraries?
I'm thinking that I could just use the SDK signal.h, and make a few complements with what's missing with a file like "my_signal.h".
So, I made a few updates to my code. Added a readme, and made a few changes. I basically just made my replacement signal.h fully compatible with the current 53.30 newlib version.
But this is somewhat cumbersome, and sometimes you can't easily change the build command line. Is it possible to somewhere in SDK, globally add extra include files, and standard link libraries?
Quote:
LIBRARY_PATH The value of LIBRARY_PATH is a colon-separated list of directories, much like PATH. When configured as a native compiler, GCC tries the directories thus specified when searching for special linker files, if it cant find them using GCC_ EXEC_PREFIX. Linking using GCC also uses these directories when searching for ordinary libraries for the -l option (but directories specified with -L come first).
Quote:
CPATH C_INCLUDE_PATH CPLUS_INCLUDE_PATH OBJC_INCLUDE_PATH Each variables value is a list of directories separated by a special character, much like PATH, in which to look for header files. The special character, PATH_ SEPARATOR, is target-dependent and determined at GCC build time. For Mi- crosoft Windows-based targets it is a semicolon, and for almost all other targets it is a colon. CPATH specifies a list of directories to be searched as if specified with -I, but after any paths given with -I options on the command line. This environment variable is used regardless of which language is being preprocessed. The remaining environment variables apply only when preprocessing the par- ticular language indicated. Each specifies a list of directories to be searched as if specified with -isystem, but after any paths given with -isystem options on the command line. In all these variables, an empty element instructs the compiler to search its current working directory. Empty elements can appear at the beginning or end of a path. For instance, if the value of CPATH is :/special/include, that has the same effect as -I. -I/special/include.
Consult the gcc manual for more variations.
And ultimately if you want to force a specific link lib to always be included you can edit the specs file, though the standard one is internal to gcc, so you will need to duplicate it as an external copy first before editing, I'd recomend against that thought TBH
I tried the proposed function implementation, but i get many errors.
which one are you talking about?
Quote:
It would be nice if a correct implementation of unistd could be part of the SDK.
define "correct" when it varies from system to system, this is why the concept of ./configure and variants exists, to work out what your system supports.
But I'll say it again AmigaOS is not POSIX, you nearly always have to do at least a little bit of work, and if the signal handling is more than trivial you will need to do some redesign because signals do not work the same way on AmigaOS as on Loonix.
correct is not the right word. The signal.h is not complete to permit a smooth port of software.
This functions and declarations are missing.
warning: implicit declaration of function 'pipe' [-Wimplicit-function-declaration]
warning: implicit declaration of function 'sigprocmask' [-Wimplicit-function-declaration] if(sigprocmask(SIG_BLOCK, &mask, &old_mask) < 0)
error: 'SIG_BLOCK' undeclared (first use in this function) if(sigprocmask(SIG_BLOCK, &mask, &old_mask) < 0)
error: 'SIG_SETMASK' undeclared (first use in this function) sigprocmask(SIG_SETMASK, &old_mask, 0);
error: 'SA_NOCLDSTOP' undeclared (first use in this function) newSigAction.sa_flags = SA_NOCLDSTOP;warning: implicit declaration of function 'pipe' [-Wimplicit-function-declaration]
warning: implicit declaration of function 'sigprocmask' [-Wimplicit-function-declaration] if(sigprocmask(SIG_BLOCK, &mask, &old_mask) < 0)
error: 'SIG_BLOCK' undeclared (first use in this function) if(sigprocmask(SIG_BLOCK, &mask, &old_mask) < 0)
error: 'SIG_SETMASK' undeclared (first use in this function) sigprocmask(SIG_SETMASK, &old_mask, 0);
error: 'SA_NOCLDSTOP' undeclared (first use in this function) newSigAction.sa_flags = SA_NOCLDSTOP;
Technically, if I understand correctly, those functions are part of the POSIX c-standard, which isn't supported. Some functions from POSIX seem to have snuck in in both newlib and clib2, but to me it seems to be more by chance than by adhering to specific standards (although I could be wrong, I haven't read the different c specs very closely). For instance, there a few signal-related functions in clib2, that aren't in newlib. But if you think that clib2 is better, you'll soon see that clib2 lacks one functions that newlib has.
But indeed, it's a bit annoying when you find these unimplemneted, or even half implemented standards. Even the pthreads library on os4depot, which has some sort of "official" status in that it has been developed by OS4 team members, lack a few pthreads function. But I guess that's also some chosen minimum version.
Exactly. Some function are present in clib2 imlementation, while other are present in newlib.
Moreover, newlib's signal.h is present in newlib/inlcude, but it's presentin newlib/inlcude/sys.
The latter seems to have more function. I haven't understand wich one is picked during compilation or if the first file call into play the second file.
Could please the SDK developer implements a more complete signal.h?
I would suggest you read up on C library signal handling in general, comparing the operation of sigprocmask() sigaction() and plain old signal(). You will find there are different variations on the APIs with different systems supporting different functions that all do similar things, ie set what hapens for different signals.
How is sigprocmask() being used in the program you are porting? Quote some code and we can suggest work arrounds using the available API (signal())
Note as I said before many of the signals aren't really emulated, you can raise() them on your own process, but not send them via kill() (only SIGINT and SIGQUIT IIRC both of whioch arrive as CTRL-C so look like SIGINT at the other end). You will never see a SIGPIPE or a SIGFPE etc.
Quote:
Exactly. Some function are present in clib2 imlementation, while other are present in newlib.
They implment differentr versions of the API.
Quote:
Moreover, newlib's signal.h is present in newlib/inlcude, but it's presentin newlib/inlcude/sys.
Yes that pretty standard, the high level part is in signal.h the lower more system dependent level parts in sys/signal.h.
Quote:
The latter seems to have more function. I haven't understand wich one is picked during compilation or if the first file call into play the second file.
Reading the src of signal.h will show you that it does
#include <sys/signal.h>
and erm incase you included sys/signal.h 'by accident' it includes signal.h at the end... "normally" you would just include the highlevel one "signal.h" .
Quote:
Could please the SDK developer implements a more complete signal.h?
Pretty much everything that is possible is possible with the current API, you just need to adapt your code slightly.
What are you porting that needs sophisticated signal handling anyway?
Even the pthreads library on os4depot, which has some sort of "official" status in that it has been developed by OS4 team members, lack a few pthreads function. But I guess that's also some chosen minimum version.
Don't ever use the pthreads implmentation from os4depot it's out of date, broken and superceded by a fresh implmentation that has been in the SDK for a long time now. The only reason for the os4depot version is to enable running of old software using it, such as the first port of perl (which is itself superceded I should add )
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
)