This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Issue: libc-lock.h
- From: "Jonathan S. Shapiro" <shap at eros-os dot org>
- To: libc-ports at sources dot redhat dot com
- Date: Fri, 23 Sep 2005 14:18:57 -0400
- Subject: Issue: libc-lock.h
We have hit our first non-obvious porting issue. At this point we are
trying to bring up a purely single-threaded version of GLIBC. When
compiling misc/mntent_r.c we end up pulling in libc-lock.h (via
stdio_ext.h)
Two questions:
1. I understand why the locking calls are present. Can they simply be
stubbed out safely in the single threaded case?
2. Is there some existing macro (or combination of macros) that can be
used to detect that multithreading is not supported in the current
build? If I stub this stuff out, I definitely want to get a #error later
when I turn multithreading support on.
3. If there is NOT a suitable set of existing macros, might it be a good
idea to add one in config.h that can be used to learn whether
--disable-threads has been passed to configure? This would allow a
"default" version of libc-lock.h to be supplied in the generic tree that
would at facilitate bringup.
Unfortunately, neither HAVE_TLS_SUPPORT nor HAVE__THREAD appears to be
the right config.h option to consult in this situation.
Adding support for this isn't very important -- I simply thought I would
ask about it. The important question above is (1).
shap