You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Martin Sebor <se...@roguewave.com> on 2005/12/01 02:02:51 UTC
Re: stdcxx question
John Benito wrote:
> Martin,
>
> Thanks for the quick and correct response. By specifying the full path
> for BUILDDIR, I get a lot farther in the process. I am now hitting a
> makefile
> issue in that mapfile.gcc-4 and no rule to make the target, and in fact
> I do
> not seem to have a mapfile.gcc-4. Do I need to download a mapfile.gcc-4?
No, I'm afraid there isn't one. The project wasn't fully ported to gcc
4 at the time of the snapshot, and this bit still isn't implemented
today (you should be able to build and use an archive library with gcc
without needing this file). You should also be able to avoid this error
when building a shared library by deleting the line that defines the
MAPFILE make variable from the generated $BUILDDIR/makefile.in file.
>
> Is there an archive I can go to see past questions, I tried
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?
> with a search for mapfile.gcc-4, but no hits.
We don't have an issue for this yet -- thanks for raising it! Let me
go ahead and enter it in the bug database. (I'm CC'ing the lists as
a cross-reference).
As for past stdcxx discussions, you can view list archives here
http://mail-archives.apache.org/mod_mbox/ but AFAIK there is no
search capability. I think Apache relies on other sites for this
functionality: http://www.apache.org/foundation/mailinglists.html
As before, if there's anything else you need help with feel free
to ask!
Martin
Re: stdcxx question
Posted by Martin Sebor <se...@roguewave.com>.
Martin Sebor wrote:
> John Benito wrote:
>
>> Martin,
>>
>> Just to let you know, while trying the 11s build on Solaris 5.10 using
>> EDG 3.5 over GCC 3.4.3 I am getting the following diagnostics. Will
>> look into away to include uint64_t this afternoon, unless you have
>> already seen this.
[...]
> The error you are seeing is triggered by an #include directive in
> assert.cpp for the <ucontext.h> header (in strict mode only):
John, I opened a bug for this and put together a simple patch. With
it I was able to compile the whole library. I haven't tested it yet
and given the libm problems I expext there to be other issues. You
can get the patch from the bug:
http://issues.apache.org/jira/browse/STDCXX-81
http://svn.apache.org/viewcvs?rev=351841&view=rev
Martin
Re: stdcxx question
Posted by Martin Sebor <se...@roguewave.com>.
John Benito wrote:
> Martin,
>
> Just to let you know, while trying the 11s build on Solaris 5.10 using
> EDG 3.5 over GCC 3.4.3 I am getting the following diagnostics. Will
> look into away to include uint64_t this afternoon, unless you have
> already seen this.
Thanks for the heads up!
I haven't seen this error yet. In fact, I haven't even got this far.
I ran into the error below during configuration (removing -lm from
the link line let me proceed).
The error you are seeing is triggered by an #include directive in
assert.cpp for the <ucontext.h> header (in strict mode only):
$ cat t.cpp && eccp -A t.cpp
#include <ucontext.h>
"/usr/include/sys/regset.h", line 304: error: identifier "uint64_t" is
undefined
uint64_t fpu_dregs[32]; /* 32 doubles */
^
"/usr/include/sys/regset.h", line 307: error: identifier "uint64_t" is
undefined
Since this works fine in Solaris 9 I suspect that eccp hasn't been
ported to Solaris 10. Let me check with EDG to see what they have
to say about it.
Martin
$ nice gmake -C../include
gmake: Entering directory `/build/sebor/eccp-3.6-11s/include'
gmake config
gmake[1]: Entering directory `/build/sebor/eccp-3.6-11s/include'
configuring for eccp-3.6 on sunos-5.10-sparc
checking if compiler is sane ok
checking if linker is sane no
int main () { return 0; }
eccp -c -A -x --template_directory=/build/sebor/eccp-3.6-11s/lib -g
--display_error_number --remarks --diag_suppress
193,236,340,401,261,479,487,678,679,815 -D_RWSTDDEBUG
-D_RWSTD_USE_CONFIG -I. a.cpp
eccp a.o --template_directory=/build/sebor/eccp-3.6-11s/lib -lm -o a.out
library "m" does not exist in the specified library directories
C++ prelinker: error: command line error
gmake[1]: *** [sane] Error 1
>
> eccp -c -I/home/benito/stdcxx-2005-07-19/include/ansi
> -D_RWSTD_USE_CONFIG -I/home/benito/stdcxx-11s/include
> -I/home/benito/stdcxx-2005-07-19/include -A -x
> --template_directory=/home/benito/stdcxx-11s/lib --display_error_number
> --remarks --diag_suppress 193,236,340,401,261,479,487,678,679,815
> /home/benito/stdcxx-2005-07-19/src/assert.cpp
> "/usr/include/sys/regset.h", line 304: error #20: identifier "uint64_t" is
> undefined
> uint64_t fpu_dregs[32]; /* 32 doubles */
> ^
> "/usr/include/sys/regset.h", line 307: error #20: identifier "uint64_t" is
> undefined
> uint64_t fpu_fsr; /* FPU status register */
> ^
> 2 errors detected in the compilation of
> "/home/benito/stdcxx-2005-07-19/src/assert.cpp".
>
> Thanks,
>
> jb -
>
> Martin Sebor wrote:
>
>> I would suggest
>>
>> make BUILDDIR=/home/benito/stdcxx-11s \
>> BUILDTYPE=11s \
>> CONFIG=eccp.config
>>
Re: stdcxx question
Posted by Martin Sebor <se...@roguewave.com>.
John Benito wrote:
> Martin,
>
> The configuration for the EDG on Solaris seems to have some issues in
> respect to the compiler command line option or maybe I am just trying to
> build something that does not make good sense (typical tester - try each
> and every option). If you try to do a BUILDMODE=shared,threads it
> passes a -shared flag to eccp, which is not a flag that EDG front-end
> recognizes.
Yes, AFAIK, there is no way to build a shared library with EDG eccp.
The EDG eccp demo also expects gcc 3.x or better as the back end but
doesn't like the binutils that g++ 3.x normally requires on Solaris.
So in my builds I set up gcc 3/4 without GNU binutils (i.e., rely on
the native system linker). That makes eccp work but doesn't let you
use the underlying g++ to link C++ code. It's kind of a pain, but
what wouldn't I do for strict conformance? ;-)
>
> BTW, I am working on a Solaris box that is running 5.10. Am currently
> seeing quite a few issues with building with EDG, is 5.10 supported?
I have 3.6 on Solaris 9 but I haven't tried it on 10 yet. Let me
give it a try and get back to you. You might be able to get a more
reliable answer straight from EDG (assuming they've tested it there).
> Have not taken the time to look at the diagnostics yet. Currently
> trying the command
>
> make BUILDDIR=/home/benito/stdcxx15d BUILDMODE=debug,threads
> CONFIG=eccp.config
I would suggest
make BUILDDIR=/home/benito/stdcxx-11s \
BUILDTYPE=11s \
CONFIG=eccp.config
Martin
>
> Thanks,
>
> jb -
>
> Martin Sebor wrote:
>
>> John Benito wrote:
>>
>>> Martin,
>>>
>>> Good, because that is what I did (commented out the MAPFILE). It
>>> seems to have built a library, will test it tomorrow. Thanks for all
>>> the help!
>>
>>
>>
>> FWIW, if you're planning to test it for conformance you should be
>> aware of the _RWSTD_STRICT_ANSI (or _RWSTD_NO_EXTENSIONS) macros
>> that, when #defined, disable most extensions. While the library
>> should be binary comatible either way you should probably build
>> it with the same setting of the macro as how you plan to test it
>> since it might also disable some extensions in the library sources.
>>
>> In addition, to achieve the the strictest possible conformance I
>> would suggest to use a recent version of EDG eccp (3.x) on Solaris.
>> With it the C library headers (such as <stddef.h> and <cstddef>)
>> do the right thing in terms of introducing the required symbols
>> only in the required namespaces and not polluting them with any
>> others. That said, due to the restriction to just the names
>> required by the C and C++ standards and nothing else the library
>> isn't terribly useful for development in this mode.
>>
>>>
>>> Happy Holidays!
>>
>>
>>
>> And happy testing to you! :)
>> Martin
>>
>>