Florian Weimer wrote:
> Since gnulib is a copylib, it doesn't have much control over how it is
> built. It's one of the issues that came up while trying to build
> things with a C++ compiler instead of a C compiler.
gnulib code is meant to be compiled with a C compiler. The header files
are suppo
Hi John,
> But how about the following example? Does it have all the required
> features? It seems to work for me
Indeed, it works for me too. Apparently it was the
'using namespace gnulib_system_namespace;' that collided with
'using gnulib::open;'.
But there's a big caveat: I don't know wheth
On 20-Feb-2010, Bruno Haible wrote:
| And when I change the first line to
|
| namespace system {
| #include
| }
| using namespace system;
|
| then there is a different error message:
|
| $ g++ -S foo.cc
| foo.cc: In function ‘int bar_uses_gnulib_implicitly()’:
| foo.cc:37: error: reference to
Ralf Wildenhues wrote:
> ... even if in the end it makes it harder to use CC=g++
I plan to make the changes conditional on
#if defined __cplusplus && defined GNULIB_NAMESPACE
So that
1. It will have no effect on CC=g++,
2. A C++ package can turn on GNULIB_NAMESPACE in some
translation
* Bruno Haible wrote on Thu, Feb 18, 2010 at 11:57:15PM CET:
> Ralf proposes:
> > I suggest you could
> > produce a helper header to #undef them again; you could even do that
> > automatically during bootstrap with above. Then only a portability
> > layer would need to avoid using these symbols in
John W. Eaton wrote:
> If I add "using gnulib::open;" inside the "#ifdef __cplusplus" block,
> ...
> then I don't even have to prefix all of the uses of open in my code
> with gnulib::. This seems like the best solution for me.
A good idea. Unfortunately I cannot see how to make it work: This pro
John W. Eaton wrote:
> Maybe I'm missing something, but what happens if @GNULIB_OPEN@ is 0?
> It doesn't look like we get the symbol inside the gnulib namespace in
> that case.
Yes. This is intentional. When @GNULIB_OPEN@ expands to 0, it means that
the programmer has not asked for the function 'o
On 19-Feb-2010, I wrote:
| To handle all the cases, I find that I need to write
|
| #ifdef __cplusplus
| namespace gnulib
| {
| int (*const open) (const char *filename, int flags, ...) =
| # if @GNULIB_OPEN@
| # if @REPLACE_OPEN@
| ::rpl_open;
| # else
| ::open;
|
On 18-Feb-2010, Bruno Haible wrote:
| Ralf proposes:
| > I suggest you could
| > produce a helper header to #undef them again; you could even do that
| > automatically during bootstrap with above. Then only a portability
| > layer would need to avoid using these symbols in another namespace.
|
|
The idiom for declaring the 'open' override can be simplified as follows,
through the definition of three new macros _GL_DECL_NAMESPACE_C,
_GL_ALIAS_RPL, _GL_ALIAS_STD.
*** lib/fcntl.in.h.orig Fri Feb 19 00:25:00 2010
--- lib/fcntl.in.h Fri Feb 19 00:14:03 2010
***
*** 79,87
Hi John,
Ralf proposes:
> I suggest you could
> produce a helper header to #undef them again; you could even do that
> automatically during bootstrap with above. Then only a portability
> layer would need to avoid using these symbols in another namespace.
This would only be a makeshift. Your exa
* John W. Eaton wrote on Thu, Feb 18, 2010 at 09:49:05PM CET:
> On 18-Feb-2010, Ralf Wildenhues wrote:
> | * John W. Eaton wrote on Thu, Feb 18, 2010 at 09:22:39PM CET:
> | > On 18-Feb-2010, Ralf Wildenhues wrote:
> | > | $ autoconf '--trace=AC_DEFINE:$1:$2' | grep ':rpl_[^:]*$'
> | >
> | > Runnin
On 18-Feb-2010, Ralf Wildenhues wrote:
| * John W. Eaton wrote on Thu, Feb 18, 2010 at 09:22:39PM CET:
| > On 18-Feb-2010, Ralf Wildenhues wrote:
| > | $ autoconf '--trace=AC_DEFINE:$1:$2' | grep ':rpl_[^:]*$'
| >
| > Running this with the Octave configure.ac file produces only
| >
| > gmtime:
* John W. Eaton wrote on Thu, Feb 18, 2010 at 09:22:39PM CET:
> On 18-Feb-2010, Ralf Wildenhues wrote:
> | $ autoconf '--trace=AC_DEFINE:$1:$2' | grep ':rpl_[^:]*$'
>
> Running this with the Octave configure.ac file produces only
>
> gmtime:rpl_gmtime
> localtime:rpl_localtime
>
> but I know
On 18-Feb-2010, Ralf Wildenhues wrote:
| Hello John,
|
| * John W. Eaton wrote on Thu, Feb 18, 2010 at 08:37:30PM CET:
| > However, there is one issue that has caused a bit of trouble as I
| > have started using more gnulib modules.
| >
| > Octave is mostly written in C++ and am having some diff
Hello John,
* John W. Eaton wrote on Thu, Feb 18, 2010 at 08:37:30PM CET:
> However, there is one issue that has caused a bit of trouble as I
> have started using more gnulib modules.
>
> Octave is mostly written in C++ and am having some difficulty with the
> rpl_ redefinitions of symbols that h
Hi,
I'm trying to use gnulib with GNU Octave and am overall very pleased,
as it is allowing me to remove a lot of cruft from Octave's source
files and just assume that a POSIX environment is available without
having to use a lot of #ifdefs. To me, that's a significant
improvement.
However, there
17 matches
Mail list logo
