Re: Are clang++ and libc++ compatible?
On Sat, 16 Nov 2013 08:54:55 -0800 Steve Kargl wrote: > On Sat, Nov 16, 2013 at 01:58:11PM +0100, Tijl Coosemans wrote: >> On Tue, 12 Nov 2013 14:40:42 -0800 Steve Kargl wrote: >>> On Tue, Nov 12, 2013 at 10:19:46PM +0100, Tijl Coosemans wrote: On Tue, 12 Nov 2013 12:19:22 -0800 Steve Kargl wrote: > This can't be good. And, unfortunately, testing math/octave shows > no better :( > > % octave > Segmentation fault (core dumped) > % ldd /usr/local/bin/octave-3.6.4 | grep ++ > libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 > (0x3c92ec000) > libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000) This could be because you enabled the OPENMP option in math/fftw3. >>> >>> Unfortuantely, that's not it. Just rebuilt fftw3 and octave still >>> dies. ldd shows that /usr/local/lib/octave/3.6.4/liboctinterp.so.1 >>> is bringing in both libc++ and libstdc++, but it is also linked >>> to 52 other libraries. >> >> USE_FORTRAN=yes currently implies USE_GCC=yes so the C++ code in >> math/octave links with libstdc++ while dependencies link with libc++. >> Gerald, is it possible to separate USE_FORTRAN from USE_GCC? > > This isn't the problem. gfortran does not pull libstdc++.so into > the build. As pointed out in another email, libGL, libGLU, fltk, > and libgraphite2 all were linked to libc++ and libstdc++. Recompiling > those ports with USE_GCC=any, fixed octave. The math/octave Makefile has USE_FORTRAN=yes (FC=gfortran46). This currently implies USE_GCC=yes (CC=gcc46, CXX=g++46) which pulls in libstdc++. If this could be changed (i.e. FC=gfortran46, CC=cc, CXX=c++) you would not have to add USE_GCC to the dependencies. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Sat, Nov 16, 2013 at 01:58:11PM +0100, Tijl Coosemans wrote: > On Tue, 12 Nov 2013 14:40:42 -0800 Steve Kargl wrote: > > On Tue, Nov 12, 2013 at 10:19:46PM +0100, Tijl Coosemans wrote: > >> On Tue, 12 Nov 2013 12:19:22 -0800 Steve Kargl wrote: > >>> This can't be good. And, unfortunately, testing math/octave shows > >>> no better :( > >>> > >>> % octave > >>> Segmentation fault (core dumped) > >>> % ldd /usr/local/bin/octave-3.6.4 | grep ++ > >>> libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 > >>> (0x3c92ec000) > >>> libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000) > >> > >> This could be because you enabled the OPENMP option in math/fftw3. > > > > Unfortuantely, that's not it. Just rebuilt fftw3 and octave still > > dies. ldd shows that /usr/local/lib/octave/3.6.4/liboctinterp.so.1 > > is bringing in both libc++ and libstdc++, but it is also linked > > to 52 other libraries. > > USE_FORTRAN=yes currently implies USE_GCC=yes so the C++ code in > math/octave links with libstdc++ while dependencies link with libc++. > Gerald, is it possible to separate USE_FORTRAN from USE_GCC? This isn't the problem. gfortran does not pull libstdc++.so into the build. As pointed out in another email, libGL, libGLU, fltk, and libgraphite2 all were linked to libc++ and libstdc++. Recompiling those ports with USE_GCC=any, fixed octave. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Tue, 12 Nov 2013 14:40:42 -0800 Steve Kargl wrote: > On Tue, Nov 12, 2013 at 10:19:46PM +0100, Tijl Coosemans wrote: >> On Tue, 12 Nov 2013 12:19:22 -0800 Steve Kargl wrote: >>> This can't be good. And, unfortunately, testing math/octave shows >>> no better :( >>> >>> % octave >>> Segmentation fault (core dumped) >>> % ldd /usr/local/bin/octave-3.6.4 | grep ++ >>> libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000) >>> libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000) >> >> This could be because you enabled the OPENMP option in math/fftw3. > > Unfortuantely, that's not it. Just rebuilt fftw3 and octave still > dies. ldd shows that /usr/local/lib/octave/3.6.4/liboctinterp.so.1 > is bringing in both libc++ and libstdc++, but it is also linked > to 52 other libraries. USE_FORTRAN=yes currently implies USE_GCC=yes so the C++ code in math/octave links with libstdc++ while dependencies link with libc++. Gerald, is it possible to separate USE_FORTRAN from USE_GCC? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?)
On Wed, Nov 13, 2013 at 12:52:16PM -0500, Ryan Stone wrote: > On Wed, Nov 13, 2013 at 11:31 AM, Marcus von Appen wrote: > > This brings up another point into which I am running with the previously > > discussed blender issue. > > > > Let's assume port A_defcompiler does not specify a compiler and c++ lib, it > > will default to libc++ and clang++ on 10.x or newer, correct? > > If now a port B_gnuish depends on port A_defcompiler, but at the same > > defines > > GCC + libstdc++, the resulting binary might link against libc++ and > > libstdc++ > > at the same time. This in turn makes the port unusable. The same applies > > to the other way around. > > > > Right now we do not have mechanism to detect and handle those flaws. > > Maintainers > > might be even less aware of those issues. Does anyone know a proper way to > > deal > > with this at the moment on 10.x+ or is this something that was missed until > > now? > > How different is this from the previous situation? As I understand it > previously A_defcompiler would be linked against the system libstdc++ > and B_gnuish would be linked against the gccXX port libstdc++. In my > experience libstdc++ does not have good ABI stability between versions > so shouldn't you have the same potential for problems? I haven't seen a problem with mixing the system's libstdc++ with a version from lang/gcc46. I can assure you that the problem is very really with libc++ vs libstdc++ within the ports collection. To getting working news/pan and math/octave, I had to recompile graphics/graphite2, graphics/libGL, graphics/libGLU, and x11-toolkits/fltk with "USE_GCC=any" to avoid the conflict. Fortunately, I have only another 360 installed ports to check for the conflict. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?)
On Wed, Nov 13, 2013 at 11:31 AM, Marcus von Appen wrote: > This brings up another point into which I am running with the previously > discussed blender issue. > > Let's assume port A_defcompiler does not specify a compiler and c++ lib, it > will default to libc++ and clang++ on 10.x or newer, correct? > If now a port B_gnuish depends on port A_defcompiler, but at the same > defines > GCC + libstdc++, the resulting binary might link against libc++ and > libstdc++ > at the same time. This in turn makes the port unusable. The same applies > to the other way around. > > Right now we do not have mechanism to detect and handle those flaws. > Maintainers > might be even less aware of those issues. Does anyone know a proper way to > deal > with this at the moment on 10.x+ or is this something that was missed until > now? How different is this from the previous situation? As I understand it previously A_defcompiler would be linked against the system libstdc++ and B_gnuish would be linked against the gccXX port libstdc++. In my experience libstdc++ does not have good ABI stability between versions so shouldn't you have the same potential for problems? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?)
https://wiki.freebsd.org/NewC++Stack says things about linking against both libc++ and libstdc++ , do they still apply? Best regards Andreas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?)
Steve Kargl : [...] Sigh. Adding USE_GCC isn't the solution. % pan Segmentation fault (core dumped) % ldd /usr/local/bin/pan | grep ++ libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c52bf000) libc++.so.1 => /usr/lib/libc++.so.1 (0x3c81ea000) This can't be good. And, unfortunately, testing math/octave shows no better :( % octave Segmentation fault (core dumped) % ldd /usr/local/bin/octave-3.6.4 | grep ++ libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000) libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000) This brings up another point into which I am running with the previously discussed blender issue. Let's assume port A_defcompiler does not specify a compiler and c++ lib, it will default to libc++ and clang++ on 10.x or newer, correct? If now a port B_gnuish depends on port A_defcompiler, but at the same defines GCC + libstdc++, the resulting binary might link against libc++ and libstdc++ at the same time. This in turn makes the port unusable. The same applies to the other way around. Right now we do not have mechanism to detect and handle those flaws. Maintainers might be even less aware of those issues. Does anyone know a proper way to deal with this at the moment on 10.x+ or is this something that was missed until now? Cheers Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Wed, Nov 13, 2013 at 9:51 AM, Zhihao Yuan wrote:
>> An implementation of the vector class might allocate all of the elements on
>> the heap lazily, but it's not required to and could equally have space for a
>> small number inside the object, expanding to something like this:
>>
>> struct Entry {
>>struct MangledNameOfVectorOfEntry {
>> size_t size;
>> Entry small[4];
>> Entry *ptr;
>>};
>> };
>
> If you don't learn C++, then just don't make claims like these. If I can
> not recursively declare std::array, which is totally allocated on
> stack with layout exactly same as T[N], I would say this implementation
> is mad.
Sorry, this part is wrong. Stack allocation does require complete type.
> A deque is more akin to an array, so in C it would be something like:
> [...]
> This is clearly nonsense - you can't have a structure that contains itself.
> [...]
These part has nothing to do with C++.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___
4BSD -- http://4bsd.biz/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Wed, Nov 13, 2013 at 2:29 AM, Shane Ambler wrote: > A possible solution I found looking into this is to wrap the Entry > reference in a std::unique_ptr - so changing - > std::deque messages; > to - > std::deque> messages; This "fix" is wrong. (Smart) pointers of T have comparison behaviors different from T itself, so this may silently change a program's runtime behavior. A better fix is to use `std::deque>`. Both libstdc++ and libc++ support vector, and vector's comparison behavior is as same as T. And of course,they both have value semantics. -- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. ___ 4BSD -- http://4bsd.biz/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Wed, Nov 13, 2013 at 5:04 AM, David Chisnall wrote:
> A deque is more akin to an array, so in C it would be something like:
> [...]
> This is clearly nonsense - you can't have a structure that contains itself.
> [...]
> An implementation of the vector class might allocate all of the elements on
> the heap lazily, but it's not required to and could equally have space for a
> small number inside the object, expanding to something like this:
>
> struct Entry {
>struct MangledNameOfVectorOfEntry {
> size_t size;
> Entry small[4];
> Entry *ptr;
>};
> };
If you don't learn C++, then just don't make claims like these. If I can
not recursively declare std::array, which is totally allocated on
stack with layout exactly same as T[N], I would say this implementation
is mad.
> It would make sense to have a std:deque or std:deque, because
> then you're only storing references or pointers to the outer structure in the
> inner structure.
It makes no sense, since you switched from value semantics to
reference semantics.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___
4BSD -- http://4bsd.biz/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On 12 Nov 2013, at 18:21, John Baldwin wrote:
>> struct foo {
>> struct foo bar;
>> }
>
> Except it isn't. It's declaring the head of a container. This is more
> like:
>
> struct foo {
> TAILQ_HEAD(, foo) messages;
> };
Eitan is correct here. The definition of std::deque is that it copies the
value that is the template argument and does not require modifications to the
layout. A deque is more akin to an array, so in C it would be something like:
struct foo {
struct foo bar[10];
};
This is clearly nonsense - you can't have a structure that contains itself.
The same is true for the deque. It's not clear what the pan people actually
wanted, but an efficient implementation of a deque would most likely contain
space for a small number of the template argument elements, so they are
literally defining a structure containing a structure containing the parent
structure. The same would be true if they did:
struct Entry {
std::vector v;
};
An implementation of the vector class might allocate all of the elements on the
heap lazily, but it's not required to and could equally have space for a small
number inside the object, expanding to something like this:
struct Entry {
struct MangledNameOfVectorOfEntry {
size_t size;
Entry small[4];
Entry *ptr;
};
};
It would make sense to have a std:deque or std:deque, because
then you're only storing references or pointers to the outer structure in the
inner structure.
David
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On 13 Nov 2013, at 08:29, Shane Ambler wrote: > On 13/11/2013 07:49, Tijl Coosemans wrote: ... >> There's a similar problem with graphics/blender. There's a class >> TreeElement which links to its parent TreeElement like this: >> >> std::map::const_iterator parent; >> >> Works with libstdc++, fails with libc++. If the standard doesn't >> specify this it would still be a very convenient extension. >> > > A possible solution I found looking into this is to wrap the Entry > reference in a std::unique_ptr - so changing - > std::deque messages; > to - > std::deque> messages; > > This turns messages into a pointer so you need to change > messages.date into messages->date With pan, this is not so easy, unfortunately. It needs changes all over the place to make it work. There was a patch for pkgsrc [1] which attempted this, but it was backed out because it caused crashes. -Dimitry [1] http://mail-index.netbsd.org/pkgsrc-changes/2013/06/16/msg091009.html signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Are clang++ and libc++ compatible?
On 13/11/2013 07:49, Tijl Coosemans wrote:
> On Tue, 12 Nov 2013 12:19:22 -0800 Steve Kargl wrote:
>> On Tue, Nov 12, 2013 at 09:55:56AM -0800, Steve Kargl wrote:
>>> On Tue, Nov 12, 2013 at 06:37:39PM +0100, Dimitry Andric wrote:
On 12 Nov 2013, at 17:54, Steve Kargl
wrote:
>
> struct Entry {
>time_t date;
>Severity severity;
>std::deque messages;
>std::string message;
>bool is_child;
>Entry() : is_child(false) { }
> };
I think the problem is that the code tries to use std::deque as a
member of struct Entry, before it is completely defined. This is not
allowed by the standard, although some libraries (e.g. GNU libstdc++)
apparently permit it for some container types.
> There's a similar problem with graphics/blender. There's a class
> TreeElement which links to its parent TreeElement like this:
>
> std::map::const_iterator parent;
>
> Works with libstdc++, fails with libc++. If the standard doesn't
> specify this it would still be a very convenient extension.
>
A possible solution I found looking into this is to wrap the Entry
reference in a std::unique_ptr - so changing -
std::deque messages;
to -
std::deque> messages;
This turns messages into a pointer so you need to change
messages.date into messages->date
This got blender compiling past that issue but I haven't got the rest
of it compiling to test that it runs.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Tue, Nov 12, 2013 at 02:40:42PM -0800, Steve Kargl wrote: > On Tue, Nov 12, 2013 at 10:19:46PM +0100, Tijl Coosemans wrote: > > On Tue, 12 Nov 2013 12:19:22 -0800 Steve Kargl wrote: > > > This can't be good. And, unfortunately, testing math/octave shows > > > no better :( > > > > > > % octave > > > Segmentation fault (core dumped) > > > % ldd /usr/local/bin/octave-3.6.4 | grep ++ > > > libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 > > > (0x3c92ec000) > > > libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000) > > > > This could be because you enabled the OPENMP option in math/fftw3. > > Unfortuantely, that's not it. Just rebuilt fftw3 and octave still > dies. ldd shows that /usr/local/lib/octave/3.6.4/liboctinterp.so.1 > is bringing in both libc++ and libstdc++, but it is also linked > to 52 other libraries. > What a rabbit hole FreeBSD has dug! Needed to recompile fltk, libGL, and libGLU with USE_GCC=any in their Makefile to eliminate octave's dependence on libc++. Octave now will start as expected. Guess I need to chase down other ports that may use fltk, libGL, and/or libGLU to ensure the new installation does not cause a new libc++ vs libstdc++ conflict. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Tue, Nov 12, 2013 at 10:19:46PM +0100, Tijl Coosemans wrote: > On Tue, 12 Nov 2013 12:19:22 -0800 Steve Kargl wrote: > > This can't be good. And, unfortunately, testing math/octave shows > > no better :( > > > > % octave > > Segmentation fault (core dumped) > > % ldd /usr/local/bin/octave-3.6.4 | grep ++ > > libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000) > > libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000) > > This could be because you enabled the OPENMP option in math/fftw3. Unfortuantely, that's not it. Just rebuilt fftw3 and octave still dies. ldd shows that /usr/local/lib/octave/3.6.4/liboctinterp.so.1 is bringing in both libc++ and libstdc++, but it is also linked to 52 other libraries. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On 12 Nov 2013, at 22:19, Tijl Coosemans wrote: ... There's a similar problem with graphics/blender. There's a class > TreeElement which links to its parent TreeElement like this: > > std::map::const_iterator parent; > > Works with libstdc++, fails with libc++. If the standard doesn't > specify this it would still be a very convenient extension. The standard explicitly says this is undefined, except for a few specific (non-container) classes in C++11. So to write portable code, you should not rely on this "feature" to be available. Besides, it is relatively easy to work around. Except for the case of pan, where it is abused all over the place, and it seems tricky to fix without overhauling a lot of code... :-/ -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Are clang++ and libc++ compatible?
On Tue, Nov 12, 2013 at 3:19 PM, Steve Kargl
wrote:
> On Tue, Nov 12, 2013 at 09:55:56AM -0800, Steve Kargl wrote:
>> On Tue, Nov 12, 2013 at 06:37:39PM +0100, Dimitry Andric wrote:
>> > On 12 Nov 2013, at 17:54, Steve Kargl
>> > wrote:
>> > >
>> > > struct Entry {
>> > >time_t date;
>> > >Severity severity;
>> > >std::deque messages;
>> > >std::string message;
>> > >bool is_child;
>> > >Entry() : is_child(false) { }
>> > > };
>> >
>> > I think the problem is that the code tries to use std::deque as a
>> > member of struct Entry, before it is completely defined. This is not
>> > allowed by the standard, although some libraries (e.g. GNU libstdc++)
>> > apparently permit it for some container types.
>> >
>> > You could try to work around it with -fdelayed-template-parsing, but I
>> > am not sure if it will help. Alternatively, compile the code with
>> > libstdc++, or rewrite it to conform. :-)
>> >
>>
>> Thanks for the suggestions. -fdelayed-template-parsing did not
>> help. (Un)fortunately, I know very little about C++, so rewriting
>> the code is not option for me. I guess I'll add a USE_GCC to the
>> port's Makefile to if it will build.
>>
>
> Sigh. Adding USE_GCC isn't the solution.
Try USES=compiler:libstd++ - I think this is the syntax required.
--
Eitan Adler
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Tue, Nov 12, 2013 at 1:21 PM, John Baldwin wrote:
> On Tuesday, November 12, 2013 1:11:04 pm Eitan Adler wrote:
>> On Tue, Nov 12, 2013 at 11:54 AM, Steve Kargl
>> wrote:
>> > On Tue, Nov 12, 2013 at 04:38:17PM +, David Chisnall wrote:
>> >> On 12 Nov 2013, at 16:32, Steve Kargl
> wrote:
>> >>
>> >>> Trying to build news/pan with clang++ dies with
>> >>>
>> >>> gmake[3]: Entering directory
> `/usr/ports/news/pan/work/pan-0.139/pan/general'
>> >>> CXXfile-util.o
>> >>> In file included from file-util.cc:38:
>> >>> In file included from ./log.h:26:
>> >>> /usr/include/c++/v1/deque:907:49: error: invalid application of 'sizeof'
> to an
>> >>> incomplete type 'value_type' (aka 'pan::Log::Entry')
>> >>>static const difference_type __block_size = sizeof(value_type) < 256
> ? 4...
>> >>>
>> >>> Anyone know how to fix either clang++ or libc++?
>> >>
>> >> The error here does not appear to be in clang or libc++, but in the
>> >> use by the thing that you are compiling.
>> >> This is saying that you have tried to create a
> std::dequeu,
>> >> but pan::Log::Entry is a forward declaration and so the template
>> >> instantiation fails.
>> >> The fix is to move the definition of pan::Log::Entry such that it
>> >> is visible at the time of its use.
>> >>
>> >
>> > I don't know C++, but it is at all like C, then the header files
>> > are normally placed at the top of a file before one's code. In
>> > this case, the code in news/pan/work/pan-0.139/pan/general/log.h
>> > looks like (where I've striped comment to keep it short)
>> >
>> > #ifndef __Log_h__
>> > #define __Log_h__
>> >
>> > #include
>> > #include
>> > #include
>> > #include
>> >
>> > namespace pan
>> > {
>> > class Log
>> > {
>> > public:
>> > enum Severity {
>> > PAN_SEVERITY_INFO = 1,
>> > PAN_SEVERITY_ERROR = 2,
>> > PAN_SEVERITY_URGENT = (1<<10)
>> > };
>> >
>> > struct Entry {
>> > time_t date;
>> > Severity severity;
>> > std::deque messages;
>> > std::string message;
>> > bool is_child;
>> > Entry() : is_child(false) { }
>> > };
>> >
>> > void add_entry(Entry& e, std::deque& list);
>> >
>> >
>> > Are you saying that I need to move '#include ' to
>> > the location above the 'void add_entry(...)' line?
>>
>> The problem here is that the code is trying to make a std::deque of
>> the type Entry before Entry is fully defined.
>> This is nearly identical to the problem in the simplified C code below:
>>
>> struct foo {
>> struct foo bar;
>> }
>
> Except it isn't. It's declaring the head of a container. This is more
> like:
>
> struct foo {
> TAILQ_HEAD(, foo) messages;
> };
>
> The problem is that unlike the queue macros (which are broken out into
> chunks), the compiler has to instantiate all of std::deque<> even though
> it will only use a portion of its definition. I understand why this is
> a limitation of C++, but it's not quite as brain damaged as your
> example.
Yes, I'm aware of this difference.
--
Eitan Adler
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
Am 12.11.2013 18:13, schrieb Zhihao Yuan: > BTW, iirc VC STL has the same issue. But libstdc++ has an honorable > history of supporting incomplete type in STL declaration. A disservice, not honorable. Nonstandard extensions, however convenient, are a pain when writing portable code. I am usually setting -std=c++11 -pedantic first up these days to avoid pitfalls later. (or -std=c11) And hope the compiler actually complains. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Tue, 12 Nov 2013 12:19:22 -0800 Steve Kargl wrote:
> On Tue, Nov 12, 2013 at 09:55:56AM -0800, Steve Kargl wrote:
>> On Tue, Nov 12, 2013 at 06:37:39PM +0100, Dimitry Andric wrote:
>>> On 12 Nov 2013, at 17:54, Steve Kargl
>>> wrote:
struct Entry {
time_t date;
Severity severity;
std::deque messages;
std::string message;
bool is_child;
Entry() : is_child(false) { }
};
>>>
>>> I think the problem is that the code tries to use std::deque as a
>>> member of struct Entry, before it is completely defined. This is not
>>> allowed by the standard, although some libraries (e.g. GNU libstdc++)
>>> apparently permit it for some container types.
>>>
>>> You could try to work around it with -fdelayed-template-parsing, but I
>>> am not sure if it will help. Alternatively, compile the code with
>>> libstdc++, or rewrite it to conform. :-)
>>
>> Thanks for the suggestions. -fdelayed-template-parsing did not
>> help. (Un)fortunately, I know very little about C++, so rewriting
>> the code is not option for me. I guess I'll add a USE_GCC to the
>> port's Makefile to if it will build.
>
> Sigh. Adding USE_GCC isn't the solution.
There's a similar problem with graphics/blender. There's a class
TreeElement which links to its parent TreeElement like this:
std::map::const_iterator parent;
Works with libstdc++, fails with libc++. If the standard doesn't
specify this it would still be a very convenient extension.
> % pan
> Segmentation fault (core dumped)
> % ldd /usr/local/bin/pan | grep ++
> libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c52bf000)
> libc++.so.1 => /usr/lib/libc++.so.1 (0x3c81ea000)
>
> This can't be good. And, unfortunately, testing math/octave shows
> no better :(
>
> % octave
> Segmentation fault (core dumped)
> % ldd /usr/local/bin/octave-3.6.4 | grep ++
> libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000)
> libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000)
This could be because you enabled the OPENMP option in math/fftw3.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Tue, Nov 12, 2013 at 09:55:56AM -0800, Steve Kargl wrote:
> On Tue, Nov 12, 2013 at 06:37:39PM +0100, Dimitry Andric wrote:
> > On 12 Nov 2013, at 17:54, Steve Kargl
> > wrote:
> > >
> > > struct Entry {
> > >time_t date;
> > >Severity severity;
> > >std::deque messages;
> > >std::string message;
> > >bool is_child;
> > >Entry() : is_child(false) { }
> > > };
> >
> > I think the problem is that the code tries to use std::deque as a
> > member of struct Entry, before it is completely defined. This is not
> > allowed by the standard, although some libraries (e.g. GNU libstdc++)
> > apparently permit it for some container types.
> >
> > You could try to work around it with -fdelayed-template-parsing, but I
> > am not sure if it will help. Alternatively, compile the code with
> > libstdc++, or rewrite it to conform. :-)
> >
>
> Thanks for the suggestions. -fdelayed-template-parsing did not
> help. (Un)fortunately, I know very little about C++, so rewriting
> the code is not option for me. I guess I'll add a USE_GCC to the
> port's Makefile to if it will build.
>
Sigh. Adding USE_GCC isn't the solution.
% pan
Segmentation fault (core dumped)
% ldd /usr/local/bin/pan | grep ++
libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c52bf000)
libc++.so.1 => /usr/lib/libc++.so.1 (0x3c81ea000)
This can't be good. And, unfortunately, testing math/octave shows
no better :(
% octave
Segmentation fault (core dumped)
% ldd /usr/local/bin/octave-3.6.4 | grep ++
libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000)
libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000)
--
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Tue, Nov 12, 2013 at 11:54 AM, Steve Kargl
wrote:
> struct Entry {
> time_t date;
> Severity severity;
> std::deque messages;
> std::string message;
> bool is_child;
> Entry() : is_child(false) { }
> };
This is a libc++ QoI issue; T should not be required to be compete
at the instantiation time of the class template itself. I'll forward this
message to libc++.
BTW, iirc VC STL has the same issue. But libstdc++ has an honorable
history of supporting incomplete type in STL declaration.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___
4BSD -- http://4bsd.biz/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Tue, Nov 12, 2013 at 11:54 AM, Steve Kargl
wrote:
> struct Entry {
> time_t date;
> Severity severity;
> std::deque messages;
> std::string message;
> bool is_child;
> Entry() : is_child(false) { }
> };
This is a libc++ QoI issue; T had better not be required to be compete
at the instantiation time of the class template itself. I've reported this
forward this issue to libc++ upstream.
BTW, iirc VC STL has the same issue. But libstdc++ has an honorable
history of supporting incomplete type in STL declaration.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___
4BSD -- http://4bsd.biz/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Tuesday, November 12, 2013 1:11:04 pm Eitan Adler wrote:
> On Tue, Nov 12, 2013 at 11:54 AM, Steve Kargl
> wrote:
> > On Tue, Nov 12, 2013 at 04:38:17PM +, David Chisnall wrote:
> >> On 12 Nov 2013, at 16:32, Steve Kargl
wrote:
> >>
> >>> Trying to build news/pan with clang++ dies with
> >>>
> >>> gmake[3]: Entering directory
`/usr/ports/news/pan/work/pan-0.139/pan/general'
> >>> CXXfile-util.o
> >>> In file included from file-util.cc:38:
> >>> In file included from ./log.h:26:
> >>> /usr/include/c++/v1/deque:907:49: error: invalid application of 'sizeof'
to an
> >>> incomplete type 'value_type' (aka 'pan::Log::Entry')
> >>>static const difference_type __block_size = sizeof(value_type) < 256
? 4...
> >>>
> >>> Anyone know how to fix either clang++ or libc++?
> >>
> >> The error here does not appear to be in clang or libc++, but in the
> >> use by the thing that you are compiling.
> >> This is saying that you have tried to create a
std::dequeu,
> >> but pan::Log::Entry is a forward declaration and so the template
> >> instantiation fails.
> >> The fix is to move the definition of pan::Log::Entry such that it
> >> is visible at the time of its use.
> >>
> >
> > I don't know C++, but it is at all like C, then the header files
> > are normally placed at the top of a file before one's code. In
> > this case, the code in news/pan/work/pan-0.139/pan/general/log.h
> > looks like (where I've striped comment to keep it short)
> >
> > #ifndef __Log_h__
> > #define __Log_h__
> >
> > #include
> > #include
> > #include
> > #include
> >
> > namespace pan
> > {
> > class Log
> > {
> > public:
> > enum Severity {
> > PAN_SEVERITY_INFO = 1,
> > PAN_SEVERITY_ERROR = 2,
> > PAN_SEVERITY_URGENT = (1<<10)
> > };
> >
> > struct Entry {
> > time_t date;
> > Severity severity;
> > std::deque messages;
> > std::string message;
> > bool is_child;
> > Entry() : is_child(false) { }
> > };
> >
> > void add_entry(Entry& e, std::deque& list);
> >
> >
> > Are you saying that I need to move '#include ' to
> > the location above the 'void add_entry(...)' line?
>
> The problem here is that the code is trying to make a std::deque of
> the type Entry before Entry is fully defined.
> This is nearly identical to the problem in the simplified C code below:
>
> struct foo {
> struct foo bar;
> }
Except it isn't. It's declaring the head of a container. This is more
like:
struct foo {
TAILQ_HEAD(, foo) messages;
};
The problem is that unlike the queue macros (which are broken out into
chunks), the compiler has to instantiate all of std::deque<> even though
it will only use a portion of its definition. I understand why this is
a limitation of C++, but it's not quite as brain damaged as your
example. The above would not be unreasonable if the foo objects should
be stored in a tree and messages was a list of the child nodes.
Depending on how this library works you might be able to shim around this by
having the dequeue store pointers instead of Entry structs.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Tue, Nov 12, 2013 at 11:54 AM, Steve Kargl
wrote:
> On Tue, Nov 12, 2013 at 04:38:17PM +, David Chisnall wrote:
>> On 12 Nov 2013, at 16:32, Steve Kargl
>> wrote:
>>
>>> Trying to build news/pan with clang++ dies with
>>>
>>> gmake[3]: Entering directory
>>> `/usr/ports/news/pan/work/pan-0.139/pan/general'
>>> CXXfile-util.o
>>> In file included from file-util.cc:38:
>>> In file included from ./log.h:26:
>>> /usr/include/c++/v1/deque:907:49: error: invalid application of 'sizeof' to
>>> an
>>> incomplete type 'value_type' (aka 'pan::Log::Entry')
>>>static const difference_type __block_size = sizeof(value_type) < 256 ?
>>> 4...
>>>
>>> Anyone know how to fix either clang++ or libc++?
>>
>> The error here does not appear to be in clang or libc++, but in the
>> use by the thing that you are compiling.
>> This is saying that you have tried to create a std::dequeu,
>> but pan::Log::Entry is a forward declaration and so the template
>> instantiation fails.
>> The fix is to move the definition of pan::Log::Entry such that it
>> is visible at the time of its use.
>>
>
> I don't know C++, but it is at all like C, then the header files
> are normally placed at the top of a file before one's code. In
> this case, the code in news/pan/work/pan-0.139/pan/general/log.h
> looks like (where I've striped comment to keep it short)
>
> #ifndef __Log_h__
> #define __Log_h__
>
> #include
> #include
> #include
> #include
>
> namespace pan
> {
> class Log
> {
> public:
> enum Severity {
> PAN_SEVERITY_INFO = 1,
> PAN_SEVERITY_ERROR = 2,
> PAN_SEVERITY_URGENT = (1<<10)
> };
>
> struct Entry {
> time_t date;
> Severity severity;
> std::deque messages;
> std::string message;
> bool is_child;
> Entry() : is_child(false) { }
> };
>
> void add_entry(Entry& e, std::deque& list);
>
>
> Are you saying that I need to move '#include ' to
> the location above the 'void add_entry(...)' line?
The problem here is that the code is trying to make a std::deque of
the type Entry before Entry is fully defined.
This is nearly identical to the problem in the simplified C code below:
struct foo {
struct foo bar;
}
--
Eitan Adler
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Tue, Nov 12, 2013 at 06:37:39PM +0100, Dimitry Andric wrote:
> On 12 Nov 2013, at 17:54, Steve Kargl
> wrote:
> >
> > struct Entry {
> >time_t date;
> >Severity severity;
> >std::deque messages;
> >std::string message;
> >bool is_child;
> >Entry() : is_child(false) { }
> > };
>
> I think the problem is that the code tries to use std::deque as a
> member of struct Entry, before it is completely defined. This is not
> allowed by the standard, although some libraries (e.g. GNU libstdc++)
> apparently permit it for some container types.
>
> You could try to work around it with -fdelayed-template-parsing, but I
> am not sure if it will help. Alternatively, compile the code with
> libstdc++, or rewrite it to conform. :-)
>
Thanks for the suggestions. -fdelayed-template-parsing did not
help. (Un)fortunately, I know very little about C++, so rewriting
the code is not option for me. I guess I'll add a USE_GCC to the
port's Makefile to if it will build.
--
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On 12 Nov 2013, at 17:54, Steve Kargl wrote:
...
> namespace pan
> {
> class Log
> {
>public:
> enum Severity {
>PAN_SEVERITY_INFO = 1,
>PAN_SEVERITY_ERROR = 2,
>PAN_SEVERITY_URGENT = (1<<10)
> };
>
> struct Entry {
>time_t date;
>Severity severity;
>std::deque messages;
>std::string message;
>bool is_child;
>Entry() : is_child(false) { }
> };
I think the problem is that the code tries to use std::deque as a
member of struct Entry, before it is completely defined. This is not
allowed by the standard, although some libraries (e.g. GNU libstdc++)
apparently permit it for some container types.
You could try to work around it with -fdelayed-template-parsing, but I
am not sure if it will help. Alternatively, compile the code with
libstdc++, or rewrite it to conform. :-)
-Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Are clang++ and libc++ compatible?
On 12 Nov 2013, at 16:54, Steve Kargl wrote:
> On Tue, Nov 12, 2013 at 04:38:17PM +, David Chisnall wrote:
>> On 12 Nov 2013, at 16:32, Steve Kargl
>> wrote:
>>
>>> Trying to build news/pan with clang++ dies with
>>>
>>> gmake[3]: Entering directory
>>> `/usr/ports/news/pan/work/pan-0.139/pan/general'
>>> CXXfile-util.o
>>> In file included from file-util.cc:38:
>>> In file included from ./log.h:26:
>>> /usr/include/c++/v1/deque:907:49: error: invalid application of 'sizeof' to
>>> an
>>> incomplete type 'value_type' (aka 'pan::Log::Entry')
>>> static const difference_type __block_size = sizeof(value_type) < 256 ?
>>> 4...
>>>
>>> Anyone know how to fix either clang++ or libc++?
>>
>> The error here does not appear to be in clang or libc++, but in the
>> use by the thing that you are compiling.
>> This is saying that you have tried to create a std::dequeu,
>> but pan::Log::Entry is a forward declaration and so the template
>> instantiation fails.
>> The fix is to move the definition of pan::Log::Entry such that it
>> is visible at the time of its use.
>>
>
> I don't know C++, but it is at all like C, then the header files
> are normally placed at the top of a file before one's code.
Yes, that's normal in C++ too.
> In
> this case, the code in news/pan/work/pan-0.139/pan/general/log.h
> looks like (where I've striped comment to keep it short)
>
> #ifndef __Log_h__
> #define __Log_h__
>
> #include
> #include
> #include
> #include
>
> namespace pan
> {
> class Log
> {
>public:
> enum Severity {
>PAN_SEVERITY_INFO = 1,
>PAN_SEVERITY_ERROR = 2,
>PAN_SEVERITY_URGENT = (1<<10)
> };
>
> struct Entry {
>time_t date;
>Severity severity;
>std::deque messages;
>std::string message;
>bool is_child;
>Entry() : is_child(false) { }
> };
>
> void add_entry(Entry& e, std::deque& list);
>
>
> Are you saying that I need to move '#include ' to
> the location above the 'void add_entry(...)' line?
No, I'm saying that the definition of struct Entry needs to be complete before
its use in the specialisation of std::deque.
I'd perhaps be able to be more helpful if you hadn't removed from the error
message the part that tells you where the error actually is...
David
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Tue, Nov 12, 2013 at 04:38:17PM +, David Chisnall wrote:
> On 12 Nov 2013, at 16:32, Steve Kargl
> wrote:
>
>> Trying to build news/pan with clang++ dies with
>>
>> gmake[3]: Entering directory `/usr/ports/news/pan/work/pan-0.139/pan/general'
>> CXXfile-util.o
>> In file included from file-util.cc:38:
>> In file included from ./log.h:26:
>> /usr/include/c++/v1/deque:907:49: error: invalid application of 'sizeof' to
>> an
>> incomplete type 'value_type' (aka 'pan::Log::Entry')
>>static const difference_type __block_size = sizeof(value_type) < 256 ?
>> 4...
>>
>> Anyone know how to fix either clang++ or libc++?
>
> The error here does not appear to be in clang or libc++, but in the
> use by the thing that you are compiling.
> This is saying that you have tried to create a std::dequeu,
> but pan::Log::Entry is a forward declaration and so the template
> instantiation fails.
> The fix is to move the definition of pan::Log::Entry such that it
> is visible at the time of its use.
>
I don't know C++, but it is at all like C, then the header files
are normally placed at the top of a file before one's code. In
this case, the code in news/pan/work/pan-0.139/pan/general/log.h
looks like (where I've striped comment to keep it short)
#ifndef __Log_h__
#define __Log_h__
#include
#include
#include
#include
namespace pan
{
class Log
{
public:
enum Severity {
PAN_SEVERITY_INFO = 1,
PAN_SEVERITY_ERROR = 2,
PAN_SEVERITY_URGENT = (1<<10)
};
struct Entry {
time_t date;
Severity severity;
std::deque messages;
std::string message;
bool is_child;
Entry() : is_child(false) { }
};
void add_entry(Entry& e, std::deque& list);
Are you saying that I need to move '#include ' to
the location above the 'void add_entry(...)' line?
--
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On 12 Nov 2013, at 16:32, Steve Kargl wrote: > Trying to build news/pan with clang++ dies with > > gmake[3]: Entering directory `/usr/ports/news/pan/work/pan-0.139/pan/general' > CXXfile-util.o > In file included from file-util.cc:38: > In file included from ./log.h:26: > /usr/include/c++/v1/deque:907:49: error: invalid application of 'sizeof' to an > incomplete type 'value_type' (aka 'pan::Log::Entry') >static const difference_type __block_size = sizeof(value_type) < 256 ? 4... > > Anyone know how to fix either clang++ or libc++? The error here does not appear to be in clang or libc++, but in the use by the thing that you are compiling. This is saying that you have tried to create a std::dequeu, but pan::Log::Entry is a forward declaration and so the template instantiation fails. The fix is to move the definition of pan::Log::Entry such that it is visible at the time of its use. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Are clang++ and libc++ compatible?
Trying to build news/pan with clang++ dies with gmake[3]: Entering directory `/usr/ports/news/pan/work/pan-0.139/pan/general' CXXfile-util.o In file included from file-util.cc:38: In file included from ./log.h:26: /usr/include/c++/v1/deque:907:49: error: invalid application of 'sizeof' to an incomplete type 'value_type' (aka 'pan::Log::Entry') static const difference_type __block_size = sizeof(value_type) < 256 ? 4... Anyone know how to fix either clang++ or libc++? -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
