Currently, uClic++ 0.2.5 fails to compile when using a long filepath.
For example, if the openwrt directory is in the path:
/tmp/this_directory_name_is_very_long/more_long_paths/.../openwrt,
then uclibc++ will cause a very obtuse error.
Although the uclibc++ makefiles do print a "File name too long" error,
it's not the final error that's printed, so it's a bit confusing:
> /bin/sh: 1:
> cannot create src/abi/libsupc/<SNIP>_libsupc++.a.dep: File name too long
> <SNIP: some other makefile output here>
> array_type_info.o: No such file or directory
Although OpenWRT 22.03 and current master branch have removed uClib++,
I thought I'd make a PR for OpenWRT 21.02, since I encountered it
and there seems to be quite a few other people experiencing the same issue.
It especially happens when using the SDK, (or when using an encrypted fs)
since the pre-packaged SDKs have very long filenames.
This patch is already in upstream [1], but has not yet been released.
[1]: https://git.busybox.net/uClibc++/commit/?id=6687fc9276fa52defaf8592f2001c19b826aec93
Signed-off-by: Alois Klink <alois@aloisklink.com>
The first allows usage of several functions in the std namespace, which
broke compilation of gddrescue specifically with uClibc-ng and uClibc++.
The second allows usage of long long with normal C++11, which is part of
the standard. Before, std=gnu++11 needed to be passsed to work around it.
As a result of the second patch, the pedantic patch can safely be removed.
Both patches are upstream backports.
Added -std=c++11 to CFLAGS to guarentee proper inclusion of long long.
Added another patch that fixes a typo with the long long support. Sent to
upstream.
Fixed up license information according to SPDX.
Small cleanups for consistency.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
This patch was originally added to fix compilation with v4l2rtspserver.
Turns out it was v4l2rtspserver that was broken, not uClibc++. This now
causes issues with a different package where the arguments are being
split.
Note that with this patch, shellcheck throws an error:
SC2068: Double quote array expansions to avoid re-splitting elements.
More: https://github.com/openwrt/packages/pull/9972#discussion_r324878373
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Switched to xz archives for smaller size.
Removed upstreamed patches.
Reorganized Makefile a little bit for clarity. Build/Prepare is not useful
anymore. Upstream converted the file to LF.
Refreshed config.
Removed -ansi option from the original CFLAGS as this was causing long
long support to be missing.
Removed fPIC. We have the macro $(FPIC) already used. No point in setting
fpic and fPIC together.
Removed pedantic -Wlong-long warnings as they are not useful.
Removed -std=gnu++98. Not only is it unnecessary (it compiles against all
standards), it actually results in a size increase. 75843 vs. 75222 (gcc
in OpenWrt defaults to g++14).
Added --gc-sections to linker flags to reduce size: 72653 vs 75222.
Removed warn linker options. They have been upstreamed.
Tested on Archer C7v2 and GnuBee PC1.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
When calling erase() on a containers derived from __base_associative
(e.g. multimap) and providing a pair of iterators a segfault will
occur.
Example code to reproduce:
typedef std::multimap<int, int> testmap;
testmap t;
t.insert(std::pair<int, int>(1, 1));
t.insert(std::pair<int, int>(2, 1));
t.insert(std::pair<int, int>(3, 1));
t.erase(t.begin(), t.end());
Signed-off-by: Ben Kelly <ben@benjii.net>
