Mail Archives: cygwin/1998/02/03/18:29:47
These are (some of) the functions you can not use unless
you do something like the following
< from libc.info .../cdk/newlib/ >
*Equivalent for errno variable:*
_errno_r
*Locale functions:*
_localeconv_r _setlocale_r
*Equivalents for stdio variables:*
_stdin_r _stdout_r _stderr_r
*Stdio functions:*
_fdopen_r _mkstemp_r _remove_r
_fopen_r _mktemp_r _rename_r
_getchar_r _perror_r _tempnam_r
_gets_r _putchar_r _tmpnam_r
_iprintf_r _puts_r _tmpfile_r
*Signal functions:*
_raise_r _signal_r
*Stdlib functions:*
_dtoa_r _realloc_r _strtoul_r
_free_r _srand_r _system_r
_malloc_r _strtod_r
_rand_r _strtol_r
*String functions:*
_strtok_r
*System functions:*
_close_r _lseek_r _stat_r
_fork_r _open_r _unlink_r
_fstat_r _read_r _wait_r
_link_r _sbrk_r _write_r
*Time function:*
_asctime_r
Code for dll's written under cygwin32, that
use the cygwin.dll libc services must initialize struct _reent.
Msvc apps that want to link in these dll's would
have to
(A) start the link with cygwin's crt0.o (to correctly initialize libc)
(B) link with libcygwin.a themselves (currently not possible except when using my patched ld.exe)
(C) call into each user dll to initialize it's copy of
struct _reent with the values of the exe's copy of
struct _reent.
I thought for a while about retrofitting B18 with
a crt0.o and dllcrt0.o that would handle this automatically.
(yes you have to go through these same hoops
when linking straight cygwin32 apps if you want to
use cygwin.dll libc services in user dll's ;^)
However I couldn't find a win32 function to enumerate the
names of linked in dll's at runtime, so that the dll init
function could be called. (I didn't look REAL hard :)
and the only other way I could think of (reading the .idata
section header of the exe) looked like it would be
a lot of trouble to implement.
Maybe you better look at mingw32 ;^)
On Tue, 3 Feb 1998 14:57:09 GMT, you wrote:
>Dear Mikey,
>
>"struct _reent for each dll needs to be initialized from
>main() before any calls to dll funcs that use the
>std file handles, see the perl5 patch for details."
>
>Thanks for this reply. Does this mean that for any program
>to use a gnuwin generated DLL, main() needs to know that it is
>a gnuwin DLL and initialise struct _reent? This would mean
>that you could not use gnuwin DLLs with code that did not
>know about _reent, I guess. Could you not can you not
>intialise _reent from the DLL code - e.g in the
>PROCESS_ATTACH routine - to initialise the Cygwin DLL from
>our new DLL?
Nope thought about that, the dll would have to know the name of the
..exe to get a handle to it, and have a callback function linked in to the .exe
to get the correct values for the exe's _reent passed back to it.
it wouldn't be that hard to write for special circumstances, but
to me it looked like a mess to use as a general solution.
>
>Does anyone have some skeletal code that does this?
>
>Thanks again,
>
>Matthew
=====================================================
Linux a platform built by, and for users, standing on
the firm legs of reliability, and speed.
Microsoft Windows, a platform without a leg to stand on.
(jeffdbREMOVETHIS AT netzone DOT com)
delete REMOVETHIS from the above to reply
Mikey
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -