`>=glibc-2.38` implements strlcpy, strlcat, etc so check for those functions
with Meson and don't provide conflicting prototypes.
Technically, it doesn't need _GNU_SOURCE, but it's easier because it's not
clear right now what glibc wants to guard it with. Note that these are in
POSIX next anyway.
Fixes: https://github.com/OpenRC/openrc/issues/643
Signed-off-by: Sam James <sam@gentoo.org>
- drop old build system
- move shared include and source files to common directory
- drop "rc-" prefix from shared include and source files
- move executable-specific code to individual directories under src
- adjust top-level .gitignore file for new build system
This closes#489.
I am removing this on the advice of a member of the Gentoo toolchain
team. It was explained to me that this doesn't offer any significant
benefits to OpenRC.
If anyone ffeels differently, please open a pull request reverting
this and adding an explanation of what it does and how to know which
functions to mark hidden in the future.
This fixes#301.
In the past, OpenRC was a hybrid of a centralized and file-scope
license/copyright structure.
I followed the instructions from the Software Freedom Law Center [1] to
convert to a Centralized structure where possible, for easier future
maintenance.
[1] https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
This reverts commit de88aff0a839844526ae262f8961ec4372fed238.
I was advised that splashutils links to libeinfo, so we do have a
consumer for this library.
The libeinfo library has no consumers other than OpenRC, so there is no
reason for it to be maintained as a library. The einfo routines are now
an object that links with the rc binary.
Add an EERROR_QUIET environment variable which works like EINFO_QUIET
but for the eerror functions. This will allow library consumers to
choose whether to suppress eerror messages separately from einfo and
ewarn messages.
X-Gentoo-Bug: 482396
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=482396
This makes the eerror* functions honor the EINFO_QUIET environment
variable like the einfo* and ewarn* functions.
X-Gentoo-Bug: 482396
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=482396
This reverts commit 4ee62c7903c65557c493f51d6703264a816156cd.
The previously referenced commit broke consistency because ewarnx() was
respecting the EINFO_QUIET environment setting, but after this commit,
ewarn() was not.
Also, due to discussion on the below referenced bugs, I think we do
want to suppress warnings when EINFO_QUIET=yes.
X-Gentoo-Bug: 482396
X-Gentoo-Bug: 439174
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=482396
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=439174
Many of these helpers are not special to librc, so split them out so they
can be used in all source trees (including libeinfo).
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The ewarn() function was affected by the EINFO_QUIET environment
variable which lead to warning messages being suppressed. Warnings
should not be suppressed.
Reported-by: Hanno Boeck <hanno@gentoo.org>
X-Gentoo-Bug: 380073
X-Gentoo-Bug-URL: http://bugs.gentoo.org/show_bug.cgi?id=380073
Rather than listing explicit object files, ignore all of them in
the whole tree.
Also ignore patch/gdb related files throughout.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Since we always want debug.mk whenever we include cc.mk, move the include
out of the Makefiles and into cc.mk itself. This also fixes an include
order bug in rc/Makefile where debug.mk is included before cc.mk and
breaks the default CFLAGS setup in cc.mk.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This allows error checking inside the included files instead of either
including the appropriate file or a blank file.
Also the blank file named .mk gets removed by this change.
Gentoo has always used the sytle:
* moo ... [ ok ]
Latest openrc now does:
* moo... [ok]
Realistically, 4 spaces out of 80 on reduced terminals doesn't make any
sort of realistic difference and it's been just fine for the last 10
years, so keep the default behavior.
