On Wed, 28 Nov 2007, guslay wrote:

> I have noticed that the status of some bugs listed in the changelog of the release are not marked as fixed in bugzilla.
> 
> g.

Bugs aren't always marked resolved right away (there's usually a day or two lag which gives reporters time to confirm and object to the fix if it's not actually fixed).  If they're your bug reports and you can confirm that the issues are indeed resolved, then feel free to go ahead and mark them resolved.

Later,
Brad

Markus Dittrich wrote:
> It looks like the only symbol requiring >=glibc-2.4 in the binary is
> 
> [dittrich@despina] readelf -s ./dmd.bin | grep GLIBC_2.4
>     69: 00000000    70 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail@GLIBC_2.4 (10)
> 
> which probably means that you used "-fstack-protector" or sth similar to compile the
> dmd source. Without it, the requirement for a newer glibc may actually go away. Otherwise, dmd.bin could also be distributed as a static binary at the cost of a (much)
> larger filesize. 

I didn't use that switch. Hmm, do both 1.0 and 2.0 dmd's have this problem?

Brad Roberts Wrote:
> 
> You can't link libc statically (for glibc at least, other os' do allow it) any more.  I forget the last version that supported it, but it might well be prior to 2.4.  Either way, it's not considered supported to build against version X of glibc and run it against any version < X, only >= even if it happens to not link against a versioned symbol (not all symbols are versioned).

Yeah, you are absolutely correct - static linking won't work for glibc. My bad :(

Markus

Walter Bright Wrote:

> Markus Dittrich wrote:
> > It looks like the only symbol requiring >=glibc-2.4 in the binary is
> > 
> > [dittrich@despina] readelf -s ./dmd.bin | grep GLIBC_2.4
> >     69: 00000000    70 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail@GLIBC_2.4 (10)
> > 
> > which probably means that you used "-fstack-protector" or sth similar to compile the dmd source. Without it, the requirement for a newer glibc may actually go away. Otherwise, dmd.bin could also be distributed as a static binary at the cost of a (much) larger filesize.
> 
> I didn't use that switch. Hmm, do both 1.0 and 2.0 dmd's have this problem?

The only thing I can think of right now is that some distros may patch their
gcc specs such that certain flags are being applied by default without
user interaction. But I don't know if this is the case for ubuntu since I've
never used it. You could always try to explicitly turn it off via
"-fno-stack-protector" (assuming that your gcc has this flag, mine does)
and see if that symbol goes away.

cheers,
Markus

Brad Roberts wrote:

> On Wed, 28 Nov 2007, guslay wrote:
> 
>> I have noticed that the status of some bugs listed in the changelog of the release are not marked as fixed in bugzilla.
>> 
>> g.
> 
> Bugs aren't always marked resolved right away (there's usually a day or two lag which gives reporters time to confirm and object to the fix if it's not actually fixed).  If they're your bug reports and you can confirm that the issues are indeed resolved, then feel free to go ahead and mark them resolved.
> 
> Later,
> Brad

I'd hope the submitter doesn't just close the bugs.  After many past issues with the GC, I was very interested in seeing more description about how the long-standing issues were fixed.

Walter, you snuck in a change to implicit template arguments, didn't you?

The following works now but failed before:
template Foo (U : Bar!(T), T) {
    pragma (msg, T.stringof);
    const bool Foo = false;
}

class Bar (T) {
    T value;
}

void main () {
    auto f = Foo!(Bar!(long));
}

Now I can fake C# attributes for classes using interfaces:
interface IFoo : ImplementedBy!(Foo) {}

Though it only works for types, so I can't do:
class Bar : DbTable!("DatabaseTableForBar") {}

Okay, that all works, but only in a shallow manner. If you add the following, it doesn't compile:

class Something : Bar!(int) {}
bool b = Foo!(Something);

A pity, that. No faking attributes yet.

Christopher Wright wrote:
> Walter, you snuck in a change to implicit template arguments, didn't you?
> 
> The following works now but failed before:
> template Foo (U : Bar!(T), T) {
>     pragma (msg, T.stringof);
>     const bool Foo = false;
> }
> 
> class Bar (T) {
>     T value;
> }
> 
> void main () {
>     auto f = Foo!(Bar!(long));
> }
> 
> Now I can fake C# attributes for classes using interfaces:
> interface IFoo : ImplementedBy!(Foo) {}
> 
> Though it only works for types, so I can't do:
> class Bar : DbTable!("DatabaseTableForBar") {}

Christopher Wright wrote:
> Okay, that all works, but only in a shallow manner. If you add the following, it doesn't compile:
> 
> class Something : Bar!(int) {}
> bool b = Foo!(Something);
> 
> A pity, that. No faking attributes yet.

Also, it doesn't work with is expressions (the spec strongly implies that it should), and you can't differentiate templates based on it. I get the feeling this isn't going to be fixed very soon, but I'll file a bug.

Christopher Wright wrote:
> Also, it doesn't work with is expressions (the spec strongly implies that it should), and you can't differentiate templates based on it. I get the feeling this isn't going to be fixed very soon, but I'll file a bug.

Yes, please file a bug on bugzilla with canonical examples. That will help a lot.

Walter Bright Wrote:

> Walter Bright wrote:
> > New const/invariant in 2.007!
> 
> er, 2.008!

The changelog for 2.008 states invariant was added to isExpression, but the on-line documentation of isExpression instead includes a second instance of interface.

http://www.digitalmars.com/d/changelog.html

http://www.digitalmars.com/d/expression.html#IsExpression