I am hitting an issues like this one:
Answer from David Carlisle says:
So, the error you show makes me suspect that you are using a class or package that is assuming an old (positively ancient:-) LaTeX2.09 definition of the figure environment without the extra colour groups, and another part of the code you are using is assuming the colour groups are there and so you get a group mis-match.
My question is: Is there a list of packages that are known to assume the ancient order of things?
This is my 476 lines of MWE which exhibits the Extra }, or forgotten \endgroup. I have really tried to make it shorter but removing seemingly innocuous lines makes it work:
\documentclass[english,]{article}
\usepackage{lmodern}
\usepackage{fontspec}
\usepackage[shorthands=off,english]{babel}
\usepackage{listings}
\usepackage[unicode=true]{hyperref}
\title{log4cplus README}
\usepackage{a4wide}
\usepackage{fancyhdr}
\usepackage{footnote}
\usepackage{listings}
\usepackage{etoolbox}
\pagestyle{fancy}
\chead{\raisebox{\baselineskip}}
\setlength{\headheight}{47.0pt}
\addtolength{\topmargin}{-4\baselineskip}
\lstset{breaklines=true,
basicstyle=\ttfamily}
\begin{document}
\maketitle
\section{Short Description}\label{short-description}
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus}
\section{Latest Project Information}\label{latest-project-information}
The
\section{Mission statement}\label{mission-statement}
The
\section{Platform support}\label{platform-support}
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus}
\begin{itemize}
\item
Windows 7 with MS Visual Studio 2015\footnote{Visual Studio 2015
Preview version was used for the test.}
\item
OpenBSD 5.6/AMD64 with GCC version 4.9.0
\item
FreeBSD 10.1/i386 with Clang version 3.4.1
(tags/RELEASE\_34/dot1-final
\begin{enumerate}
\def\labelenumi{\arabic{enumi})}
\setcounter{enumi}{208031}
\item
\end{enumerate}
\item
NetBSD 6.1.5/AMD64 with GCC version 4.9.1
\item
DragonflyBSD 4.0.1/AMD64 with GCC version 4.9.3 20141126 (prerelease)
(FreeBSD Ports Collection)
\item
Minix 3.3.0/i386 with Clang version 3.4 (branches/release\_34) with
\lstinline!--disable-threads!
\end{itemize}
The
The
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus}. They
either do not have a reasonable C++11 capable compiler or have not been
checked with
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} 2.x, yet:
\begin{itemize}
\item
OpenSolaris with \lstinline!-library=stlport4!
\item
Solaris with \lstinline!-library=stlport4! and with
\lstinline!-library=Cstd!.
\item
Solaris 5.10/Sparc
\item
MacOS X 10.8
\item
MacOS X 11.4.2
\item
HP-UX (hppa2.0w-hp-hpux11.11)
\item
Haiku R1 Alpha 4.1
\item
AIX 5.3 with IBM XL C/C++ for AIX
\end{itemize}
\section{Configure script options}\label{configure-script-options}
\subsection{\texorpdfstring{\lstinline!--enable-debugging!}{-\/-enable-debugging}}\label{enable-debugging}
This . This option mainly affects GCC
builds but it also has some limited effect on non-GCC builds. It turns
on debugging information generation, undefines \lstinline!NDEBUG! symbol
and adds \lstinline!-fstack-check! (GCC).
\subsection{\texorpdfstring{\lstinline!--enable-warnings!}{-\/-enable-warnings}}\label{enable-warnings}
This option is enabled by default. It adds platform / compiler dependent
warning options to compiler command line.
\subsection{\texorpdfstring{\lstinline!--enable-so-version!}{-\/-enable-so-version}}\label{enable-so-version}
This option is enabled by default. It enables SO version decoration on
resulting library file, e.g., the \lstinline!.2.0.0! in
\lstinline!liblog4cplus-1.2.so.2.0.0!.
\subsection{\texorpdfstring{\lstinline!--enable-release-version!}{-\/-enable-release-version}}\label{enable-release-version}
This option is enabled by default. It enables release version decoration
on the resulting library file, e.g., the \lstinline!-1.2! in
\lstinline!liblog4cplus-1.2.so.2.0.0!.
\subsection{\texorpdfstring{\lstinline!--enable-symbols-visibility-options!}{-\/-enable-symbols-visibility-options}}\label{enable-symbols-visibility-options}
This option is enabled by default. It enables use of compiler and
platform specific option for symbols visibility. See also the
\href{http://gcc.gnu.org/wiki/Visibility}{Visibility} page on GCC Wiki.
\subsection{\texorpdfstring{\lstinline!--enable-profiling!}{-\/-enable-profiling}}\label{enable-profiling}
This option is disabled by default. This option adds profiling
information generation compiler option \lstinline!-pg! to GCC and Sun CC
/ Solaris Studio builds.
\subsection{\texorpdfstring{\lstinline!--enable-threads!}{-\/-enable-threads}}\label{enable-threads}
This option is enabled by default. It turns on detection of necessary
compiler and linker flags that enable POSIX threading support.
While this detection usually works well, some platforms still need help
with configuration by supplying additional flags to the
\lstinline!configure! script. One of the know deficiencies is Solaris
Studio on Linux. See one of the later note for details.
\subsection{\texorpdfstring{\lstinline!--with-wchar_t-support!}{-\/-with-wchar\_t-support}}\label{with-wcharux5ft-support}
This option is enabled by default. When enabled, additional binaries
will be built, marked with \lstinline!U! suffix in file name and
compiled with \lstinline!-DUNICODE=1! flag. In effect, these binaries
assume that \lstinline!log4cplus::tchar! is \lstinline!wchar_t!.
\subsection{\texorpdfstring{\lstinline!--with-working-locale!}{-\/-with-working-locale}}\label{with-working-locale}
This
It is know to work well with GCC on Linux. Other platforms generally
have lesser locale support in their implementations of the C++ standard
library. It is known not to work well on any BSDs.
See also docs/unicode.txt.
\subsection{\texorpdfstring{\lstinline!--with-working-c-locale!}{-\/-with-working-c-locale}}\label{with-working-c-locale}
This is second of \lstinline!wchar_t!↔\lstinline!char! conversion
related options. It is disabled by default.
It is known to work well on most Unix--like platforms, including recent
Cygwin.
\subsection{\texorpdfstring{\lstinline!--with-iconv!}{-\/-with-iconv}}\label{with-iconv}
This
The \lstinline!"UTF-8"!
and \lstinline!"WCHAR_T"! source/target encoding. It is known to work
well on platforms with GNU iconv. Different implementations of
\lstinline!iconv()! might not support \lstinline!"WCHAR_T"! encoding
selector.
Either system provided \lstinline!iconv()! or library provided
\lstinline!libiconv()! are detected and accepted. Also both SUSv3 and
GNU \lstinline!iconv()! function signatures are accepted.
\subsection{\texorpdfstring{\lstinline!--with-qt!}{-\/-with-qt}}\label{with-qt}
This option is disabled by default. It enables compilation of a separate
shared library (liblog4cplusqt4debugappender) that implements
\lstinline!Qt4DebugAppender!. It requires Qt4 and pkg-config to be
installed.
\subsection{\texorpdfstring{\lstinline!--enable-unit-tests!}{-\/-enable-unit-tests}}\label{enable-unit-tests}
This option is disabled by default. It enables compilation of unit tests
along their units. These unit tests then can be executed through
\lstinline!unit_tests! test executable that is built during compilation.
\section{Notes}\label{notes}
\subsection{Compilation}\label{compilation}
On Unix--like platforms,
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} can be
compiled using either autotools based build system or using CMake build
system. The autotools based build system is considered to be primary for
Unix--like platforms.
On Windows, the primary build system is Visual Studio 2010 solution and
projects (\lstinline!msvc14/log4cplus.sln!). This solution and
associated project files should update just fine to Visual Studio 2012
out of the box. See also \lstinline!scripts/msvc14_to_msvc11.cmd! and
\lstinline!scripts/msvc14_to_msvc12.cmd! helper scripts that create
\lstinline!msvc11/log4cplus.sln! and \lstinline!msvc12/log4cplus.sln!
respectively when invoked on \lstinline!msvc14/log4cplus.sln! from
source root directory.
MinGW is supported by autotools based build system. CMake build system
is supported as well and it should be used to compile
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} with older
versions of Visual Studio or with less common compiler suites (e.g.,
Embarcadero, Code::Blocks, etc.).
\subsection{Cygwin/MinGW}\label{cygwinmingw}
Some version of GCC (3.4.x and probably some of 4.x series too) on
Windows (both MinGW and Cygwin) produces lots of warnings of the form:
\begin{lstlisting}
warning: inline function 'void foo()' is declared as dllimport: attribute ignored
\end{lstlisting}
This can be worked around by adding \lstinline!-Wno-attributes! option
to GCC command. Unfortunately, not all affected version of GCC have this
option.
\subsection{MinGW and MSVCRT version}\label{mingw-and-msvcrt-version}
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} can use
functions like \lstinline!_vsnprintf_s()! (Microsoft's secure version of
\lstinline!vsnprintf()!). MinGW tool--chains (by default) link to the
system \lstinline!MSVCRT.DLL!. Unfortunately, older systems, like
Windows XP, ship with \lstinline!MSVCRT.DLL! that lacks these functions.
It is possible to compile
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} with MinGW
tool--chains but \emph{without} using Microsoft's secure functions by
defining \lstinline!__MSVCRT_VERSION__! to value less than
\lstinline!0x900! and vice versa.
\begin{lstlisting}
$ ../configure CPPFLAGS="-D__MSVCRT_VERSION__=0x700"
\end{lstlisting}
\subsection{Windows and TLS}\label{windows-and-tls}
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} uses
thread--local storage (TLS) for NDC, MDC and to optimize use of some
temporary objects. On Windows there are two ways to get TLS:
\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\itemsep1pt\parskip0pt\parsep0pt
\item
using \lstinline!TlsAlloc()!, etc., functions
\item
using \lstinline!__declspec(thread)!
\end{enumerate}
While method (2) generates faster code, it has
\href{http://support.microsoft.com/kb/118816/en-us}{some limitations
prior to Windows Vista}. If \lstinline!log4cplus.dll! is loaded at run
time using \lstinline!LoadLibrary()! (or as a dependency of such loaded
library), then accessing \lstinline!__declspec(thread)! variables can
cause general protection fault (GPF) errors. This is because Windows
prior to Windows Vista do not extend the TLS for libraries loaded at run
time using \lstinline!LoadLibrary()!. To allow using the best available
method, \href{https://sourceforge.net/projects/log4cplus/}{log4cplus}
enables the method (2) by checking \lstinline!_WIN32_WINNT >= 0x0600!
condition, when compiling
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} targeted
to Windows Vista or later.
\subsection{Android, TLS and CMake}\label{android-tls-and-cmake}
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} uses
thread--local storage (TLS, see ``Windows and TLS'' for details). On the
Android platform, when
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} is being
compiled using the \lstinline!android/android.toolchain.cmake!, you
might get errors featuring the \lstinline!__emutls! symbol:
\begin{lstlisting}
global-init.cxx:268:46: error: log4cplus::internal::__emutls_t._ZN9log4cplus8internal3ptdE causes a section type conflict with log4cplus::internal::ptd
\end{lstlisting}
To work around this issue, invoke CMake with
\lstinline!-DANDROID_FUNCTION_LEVEL_LINKING:BOOL=OFF! option.
\subsection{Threads and signals}\label{threads-and-signals}
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} is not
safe to be used from asynchronous signals' handlers. This is a property
of most threaded programmes in general. If you are going to use
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} in
threaded application and if you want to use
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} from
signal handlers then your only option is to block signals in all threads
but one that will handle all signals. On POSIX platforms, this is
possible using the \lstinline!sigwait()! call.
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} enables
this approach by blocking all signals in any threads created through its
threads helpers.
\subsection{IBM's XL C/C++ compiler}\label{ibms-xl-cc-compiler}
IBM's XL C/C++ compiler executable has
\href{http://pic.dhe.ibm.com/infocenter/comphelp/v121v141/index.jsp?topic=\%2Fcom.ibm.xlcpp121.aix.doc\%2Fcompiler_ref\%2Ftucmpinv.html}{many
variants}. To compile
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} with
threading support specify one of the compiler variants that support
threading using the \lstinline!CXX! variable on \lstinline!configure!
script command line. E.g.:
\begin{lstlisting}
\end{lstlisting}
\subsection{AIX reentrancy problem}\label{aix-reentrancy-problem}
There appears to be a reentracy problem with AIX 5.3 and xlC 8 which can
result into a deadlock condition in some circumstances. It is unknown
whether the problem manifests with other versions of either the OS or
the compiler, too. The problem was initially reported in a bug report
\href{http://sourceforge.net/p/log4cplus/bugs/103/}{\#103}.
The core of the problem is that IBM's/xlC's standard C++ IOStreams
implementation uses global non recursive lock to protect some of its
state. The application in the bug report was trying to do logging using
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} from
inside \lstinline!overflow()! member function of a class derived from
\lstinline!std::streambuf! class.
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} itself
uses \lstinline!std::ostringstream!. This resulted into an attempt to
recursively lock the global non recursive lock and a deadlock.
\subsection{Solaris / SunOS}\label{solaris-sunos}
Some older version of this operating system might have problems linking
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} due to
\href{https://groups.google.com/d/msg/comp.unix.solaris/AAMqkK0QZ6U/zlkVKA1L_QcJ}{missing
\lstinline!__tls_get_addr!} in their unpatched state.
\subsection{Solaris Studio}\label{solaris-studio}
Solaris Studio compilers' default standard C++ library is very
non-standard. It seems that it is not conforming enough in, e.g., Sun
C++ 5.12 Linux\_i386 2011/11/16 (missing \lstinline!std::time_t!, etc.),
but it works well enough on Solaris with Sun C++ 5.8 2005/10/13. Thus
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} adds
\lstinline!-library=stlport4! to the \lstinline!CXXFLAGS! environment
variable, unless a switch matching
\lstinline!-library=(stlport4|stdcxx4|Cstd)! is already present there.
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus}, just set
it into \lstinline!CXXFLAGS! on \lstinline!configure! script command
line.
Solaris Studio supports the \lstinline!__func__! symbol which can be
used by \href{https://sourceforge.net/projects/log4cplus/}{log4cplus} to
record function name in logged events. To enable this feature, add
\lstinline!-features=extensions! switch to \lstinline!CXXFLAGS! for
\lstinline!configure! script. Subsequently, you will have to add this
switch to your application's build flags as well.
\subsection{Solaris Studio on
GNU/Linux}\label{solaris-studio-on-gnulinux}
The autotools and our \lstinline!configure.ac! combo does not handle
Solaris Studio compiler on Linux well enough and needs a little help
with configuration of POSIX threads:
\begin{lstlisting}[language=bash]
$ COMMON_FLAGS="-L/lib/x86_64-linux-gnu/ \
-L/usr/lib/x86_64-linux-gnu/ -mt=yes -O"
$ ../configure --enable-threads=yes \
CC=/opt/solarisstudio12.3/bin/cc \
CXX=/opt/solarisstudio12.3/bin/CC \
CFLAGS="$COMMON_FLAGS" \
CXXFLAGS="$COMMON_FLAGS" \
LDFLAGS="-lpthread"
\end{lstlisting}
\subsection{\texorpdfstring{HP-UX with
\lstinline!aCC!}{HP-UX with aCC}}\label{hp-ux-with-acc}
It is necessary to turn on C++98 mode of \lstinline!aCC! by providing
the \lstinline!-AA! flag:
\begin{lstlisting}
$ ../configure --enable-threads=yes CXXFLAGS="-AA"
\end{lstlisting}
\subsection{\texorpdfstring{HP-UX with \lstinline!aCC! on
IA64}{HP-UX with aCC on IA64}}\label{hp-ux-with-acc-on-ia64}
There is a problem on IA64 HP-UX with \lstinline!aCC! (HP C/aC++ B3910B
A.06.20). The problem manifests as
\href{http://h30499.www3.hp.com/t5/Languages-and-Scripting/Building-Log4cplus-fails-with-quot-ld-Unsatisfied-symbol-virtual/td-p/6261411\#.UoHtgPmet8G}{unsatisfied
symbols during linking of \lstinline!loggingserver!}:
\begin{lstlisting}
ld:
\end{lstlisting}
The problem appears to be a deficiency in \lstinline!aCC! and its
support of \lstinline!__declspec(dllexport)!. To work around this issue,
add \lstinline!--disable-symbols-visibility-options! to
\lstinline!configure! script command line:
\begin{lstlisting}
$
\end{lstlisting}
\subsection{Haiku}\label{haiku}
Haiku is supported with GCC 4+. The default GCC version in Haiku is set
to version 2 (based on GCC 2.95.x). To change the default GCC version to
version 4, please run \lstinline!setgcc gcc4! command. This is to avoid
linking errors like this:
\begin{lstlisting}
main.cpp:(.text.startup+0x54a): undefined reference to `_Unwind_Resume'
\end{lstlisting}
Running the command switches the \emph{current} GCC version to version
4. This change is permanent and global. See also Haiku ticket
\href{http://dev.haiku-os.org/ticket/8368}{\#8368}.
\subsection{Qt4 / Win32 / MSVC}\label{qt4-win32-msvc}
In order to use
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} in Qt4
programs it is necessary to set following option:
\lstinline!Treat WChar_t As Built in Type: No (/Zc:wchar_t-)!
Set this option for
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} project
and \lstinline!Qt4DebugAppender! project in MS Visual Studio. Remember
to use Unicode versions of
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} libraries
with Qt. It is also necessary to make clear distinction between debug
and release builds of Qt project and
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus}. Do not
use \href{https://sourceforge.net/projects/log4cplus/}{log4cplus}
release library with debug version of Qt program and vice versa.
For registering Qt4DebugAppender library at runtime, call this function:
\lstinline!log4cplus::Qt4DebugAppender::registerAppender()!
\href{https://sourceforge.net/projects/log4cplus/}{log4cplus} and
\lstinline!Qt4DebugAppender!:
\begin{lstlisting}
INCLUDEPATH += C:\log4cplus\include
win32 {
CONFIG(debug, debug|release) {
LIBS += -LC:\log4cplus\msvc14\Win32\bin.Debug_Unicode -llog4cplusUD
LIBS += -LC:\log4cplus\msvc14\Win32\bin.Debug_Unicode -llog4cplus-Qt4DebugAppender
} else {
LIBS += -LC:\log4cplus\msvc14\Win32\bin.Release_Unicode -llog4cplusU
LIBS += -LC:\log4cplus\msvc14\Win32\bin.Release_Unicode -llog4cplus-Qt4DebugAppender
}
}
\end{lstlisting}
\end{document}
And the error:
[][]\EU2/lmr/m/n/10 For reg-is-ter-ing Qt4De-bugAp-pen-der li-brary at run-time
, call this func-tion: [][][][][]
! Extra }, or forgotten \endgroup.
<recently read> \egroup
l.473 }
Best Answer
You misunderstood my reply to the referenced question.
Is just the generic error that you have the grouping wrong it happens all the time something simple like a stray
}in an environment.But that is not the important part or the error message in the referenced question. In that case the error message goes on to say:
That is what identifies it as related to the change to
\end{figure}in 1993 when\color@endboxwas added.In your case note the error is not triggered by
\end{figure}but bythat is, a potentially stray
}on line 473.Your main error here is using
\lstinlinein the argument of another command, like most verbatim constructs that does not work. You almost got away with it except in the last case, the page break happens inside a listings block so you end up calling listings recursively inside itself and things go wrong.I also deleted the
\cheadsetting that had a\raiseboxwith no argument, andmoved hyperef later.