On Sat, 22 Jun 2013 00:27:53 +0200
Dimitry Andric wrote:
> > No, db5 does not build because it is redefining a C++11 standard
> > library identifier, atomic_init(). It should probably prefix all
> > its internal defines with 'db_', to avoid collisions. The
> > db-5.3.21/src/dbinc/atomic.h file
On Thu, 27 Jun 2013 00:28:33 +0300
Konstantin Belousov wrote:
> On Wed, Jun 26, 2013 at 11:17:41PM +0200, Michael Gmelin wrote:
> > Are you both on the same architecture?
>
> I tested both on amd64 and i386. For i386, it was -m32 for clang, and
> native 32bit gcc 4.8.1, stock build from the tarb
On Wed, Jun 26, 2013 at 11:17:41PM +0200, Michael Gmelin wrote:
> Are you both on the same architecture?
I tested both on amd64 and i386. For i386, it was -m32 for clang, and
native 32bit gcc 4.8.1, stock build from the tarball.
pgpx_vSDnRqU4.pgp
Description: PGP signature
On Wed, 26 Jun 2013 23:11:34 +0200
Dimitry Andric wrote:
> On Jun 26, 2013, at 23:05, Konstantin Belousov
> wrote:
> > On Wed, Jun 26, 2013 at 10:59:24PM +0200, Dimitry Andric wrote:
> >> On Jun 26, 2013, at 22:45, Konstantin Belousov
> >> wrote:
> >>> On Wed, Jun 26, 2013 at 09:26:09PM +0200,
On Jun 26, 2013, at 23:05, Konstantin Belousov wrote:
> On Wed, Jun 26, 2013 at 10:59:24PM +0200, Dimitry Andric wrote:
>> On Jun 26, 2013, at 22:45, Konstantin Belousov wrote:
>>> On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote:
This revision is not in 9.1-RELEASE, but it is
On Thu, 27 Jun 2013 00:05:34 +0300
Konstantin Belousov wrote:
> On Wed, Jun 26, 2013 at 10:59:24PM +0200, Dimitry Andric wrote:
> > On Jun 26, 2013, at 22:45, Konstantin Belousov
> > wrote:
> > > On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote:
> > >> This revision is not in 9.1-R
On Wed, Jun 26, 2013 at 10:59:24PM +0200, Dimitry Andric wrote:
> On Jun 26, 2013, at 22:45, Konstantin Belousov wrote:
> > On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote:
> >> This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so the
> >> problem can also be reproduced th
On Jun 26, 2013, at 22:45, Konstantin Belousov wrote:
> On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote:
>> This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so the
>> problem can also be reproduced there.
> ...
>> This is roughly gcc 4.3.0 and later. For example, gcc 4.8
On Wed, Jun 26, 2013 at 10:51:37PM +0200, Michael Gmelin wrote:
> Could you replicate the problem using clang on stable/9 and HEAD? (I
> didn't test gcc > 4.2.1 myself).
On stable no, it is not reproducable. As I understand, stable clang is
3.2-something.
On HEAD with clang, I do see the indentat
On Wed, 26 Jun 2013 23:45:21 +0300
Konstantin Belousov wrote:
> On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote:
> > This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so the
> > problem can also be reproduced there.
> ...
> > This is roughly gcc 4.3.0 and later. For exam
On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote:
> This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so the
> problem can also be reproduced there.
...
> This is roughly gcc 4.3.0 and later. For example, gcc 4.8 generates:
I just tested the thing with gcc 4.8 on up to date
On Wed, 26 Jun 2013 21:26:09 +0200
Dimitry Andric wrote:
> On Jun 26, 2013, at 13:31, Michael Gmelin wrote:
> > On Wed, 26 Jun 2013 11:00:40 +0200
> > Dimitry Andric wrote:
> >> On 2013-06-26 01:55, Michael Gmelin wrote:
> >> ...
> >>> The problem is that static initialization happens in the ex
On Jun 26, 2013, at 13:31, Michael Gmelin wrote:
> On Wed, 26 Jun 2013 11:00:40 +0200
> Dimitry Andric wrote:
>> On 2013-06-26 01:55, Michael Gmelin wrote:
>> ...
>>> The problem is that static initialization happens in the expected
>>> order (same translation unit), but termination does *not* ha
On Wed, 26 Jun 2013 11:00:40 +0200
Dimitry Andric wrote:
> On 2013-06-26 01:55, Michael Gmelin wrote:
> ...
> > The problem is that static initialization happens in the expected
> > order (same translation unit), but termination does *not* happen in
> > the reverse order of initialization, which
On 2013-06-26 01:55, Michael Gmelin wrote:
...
The problem is that static initialization happens in the expected
order (same translation unit), but termination does *not* happen in the
reverse order of initialization, which - according to the C++ standard
section 3.6.3 should be guaranteed:
"If
On Sat, 22 Jun 2013 00:27:53 +0200
Dimitry Andric wrote:
> On Jun 21, 2013, at 22:07, Dimitry Andric wrote:
> > On Jun 13, 2013, at 03:15, Michael Gmelin wrote:
> > ...
Hi Dimitry,
Despite my patch to mitigate the problem I discussed and analyzed the
initialization order issue and I think the
Am 24.06.2013 21:15, schrieb Dimitry Andric:
> On Jun 24, 2013, at 20:23, Michael Gmelin wrote:
>> On Mon, 24 Jun 2013 19:58:26 +0200
>> Matthias Andree wrote:
>>> Am 22.06.2013 00:27, schrieb Dimitry Andric:
>>>
Attached is a diff to fix the db5 port, so it correctly builds with
CXXFLA
On Jun 24, 2013, at 20:23, Michael Gmelin wrote:
> On Mon, 24 Jun 2013 19:58:26 +0200
> Matthias Andree wrote:
>> Am 22.06.2013 00:27, schrieb Dimitry Andric:
>>
>>> Attached is a diff to fix the db5 port, so it correctly builds with
>>> CXXFLAGS?=-std=c++11 -stdlib=libc++. Matthias, could you
On Mon, 24 Jun 2013 19:58:26 +0200
Matthias Andree wrote:
> Am 22.06.2013 00:27, schrieb Dimitry Andric:
>
> > Attached is a diff to fix the db5 port, so it correctly builds with
> > CXXFLAGS?=-std=c++11 -stdlib=libc++. Matthias, could you please
> > have a look at it?
>
> Does databases/db6 a
Am 22.06.2013 00:27, schrieb Dimitry Andric:
> Attached is a diff to fix the db5 port, so it correctly builds with
> CXXFLAGS?=-std=c++11 -stdlib=libc++. Matthias, could you please have a
> look at it?
Does databases/db6 as a requisite make your failing port compile properly?
___
On Sun, 23 Jun 2013 22:16:07 +0200
Michael Gmelin wrote:
> On Sun, 23 Jun 2013 08:09:05 +0200
> Michael Gmelin wrote:
>
> > On Sat, 22 Jun 2013 00:27:53 +0200
> > Dimitry Andric wrote:
> >
> > > On Jun 21, 2013, at 22:07, Dimitry Andric wrote:
> > > > On Jun 13, 2013, at 03:15, Michael Gme
On Sun, 23 Jun 2013 08:09:05 +0200
Michael Gmelin wrote:
> On Sat, 22 Jun 2013 00:27:53 +0200
> Dimitry Andric wrote:
>
> > On Jun 21, 2013, at 22:07, Dimitry Andric wrote:
> > > On Jun 13, 2013, at 03:15, Michael Gmelin wrote:
> > ...
> > >> - system clang + std=c++11 + system libc++: Build
On Sat, 22 Jun 2013 00:27:53 +0200
Dimitry Andric wrote:
> On Jun 21, 2013, at 22:07, Dimitry Andric wrote:
> > On Jun 13, 2013, at 03:15, Michael Gmelin wrote:
> ...
> >> - system clang + std=c++11 + system libc++: Build fails, due to
> >> a dependency (databases/db5) not building with those
On Jun 21, 2013, at 22:07, Dimitry Andric wrote:
> On Jun 13, 2013, at 03:15, Michael Gmelin wrote:
...
>> - system clang + std=c++11 + system libc++: Build fails, due to
>> a dependency (databases/db5) not building with those flags. It looks
>> like a problem in libc++ to me, but I didn't have
On Fri, 21 Jun 2013 22:07:56 +0200
Dimitry Andric wrote:
> On Jun 13, 2013, at 03:15, Michael Gmelin wrote:
> > I've been waiting for
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=179233 to get committed
> > for a little while now.
> >
> > The person looking at it today decided to test it on 1
On Jun 13, 2013, at 03:15, Michael Gmelin wrote:
> I've been waiting for http://www.freebsd.org/cgi/query-pr.cgi?pr=179233
> to get committed for a little while now.
>
> The person looking at it today decided to test it on 10-CURRENT, which
> failed (it built, but unit tests fail with all kinds o
On Fri, Jun 14, 2013 at 2:36 PM, Michael Gmelin wrote:
> On Thu, 13 Jun 2013 08:24:18 +0200
> Matthias Apitz wrote:
>
>> El día Thursday, June 13, 2013 a las 08:07:14AM +0200, Eitan Adler
>> escribió:
>>
>> > On Thu, Jun 13, 2013 at 3:15 AM, Michael Gmelin
>> > wrote:
>> > > So my question is: A
On Thu, 13 Jun 2013 08:24:18 +0200
Matthias Apitz wrote:
> El día Thursday, June 13, 2013 a las 08:07:14AM +0200, Eitan Adler
> escribió:
>
> > On Thu, Jun 13, 2013 at 3:15 AM, Michael Gmelin
> > wrote:
> > > So my question is: Are we port maintainers now really supposed to
> > > make ports wor
On Thu, 13 Jun 2013 08:07:14 +0200
Eitan Adler wrote:
> On Thu, Jun 13, 2013 at 3:15 AM, Michael Gmelin
> wrote:
> > So my question is: Are we port maintainers now really supposed to
> > make ports work with CURRENT?
>
> This is generally up to the maintainer; however many committers run
> -CUR
On Thu, 13 Jun 2013 07:20:13 +0100
Chris Rees wrote:
> It's worth bearing in mind that head becomes a release every so
> often. If you don't make sure your ports build there, it makes life
> harder for people running and testing it, and makes for a mad rush
> and scramble to fix broken ports bef
El día Thursday, June 13, 2013 a las 08:07:14AM +0200, Eitan Adler escribió:
> On Thu, Jun 13, 2013 at 3:15 AM, Michael Gmelin wrote:
> > So my question is: Are we port maintainers now really supposed to make
> > ports work with CURRENT?
>
> This is generally up to the maintainer; however many c
It's worth bearing in mind that head becomes a release every so often. If you
don't make sure your ports build there, it makes life harder for people running
and testing it, and makes for a mad rush and scramble to fix broken ports
before a major release.
Since the port can often be fixed with
On Thu, Jun 13, 2013 at 3:15 AM, Michael Gmelin wrote:
> So my question is: Are we port maintainers now really supposed to make
> ports work with CURRENT?
This is generally up to the maintainer; however many committers run
-CURRENT and test on that by default.
I would add something like
.if ${OS
Hi,
I've been waiting for http://www.freebsd.org/cgi/query-pr.cgi?pr=179233
to get committed for a little while now.
The person looking at it today decided to test it on 10-CURRENT, which
failed (it built, but unit tests fail with all kinds of bus errors
on exit). It's not entirely clear what the
34 matches
Mail list logo
