I wanted to use dmd at another site, so I took my laptop and the latest dmd 2 zip.

All went well, till I ran dmd, and got an error message about it needing a newer libc, I had only libc-2.3.5.so on a Fedora version from 2005.

I thought some expletives about software vendors always compiling their products on the absolutely latest OS version, thus introducing gratuitous dependencies on brand-new libraries, where most often they could compile with a 5 year old version, and make clients happy.

But, thanks to Walter, /I had the source/, so I compiled dmd from scratch. I got a surprise when I tried to use it. Errors I can't figure out:

$ cat foo.d
import std.stdio;

void main(){}

$ dmd foo.d
/home/georg/lang/d/dmd/linux/bin/../../src/phobos/std/traits.d(855): template instance isStaticArray!(const(int)[]) does not match template declaration isStaticArray(T : U[N],U,uint N)
/home/georg/lang/d/dmd/linux/bin/../../src/phobos/std/traits.d(855): Error: expression isStaticArray!(const(int)[]) of type void does not have a boolean value
/home/georg/lang/d/dmd/linux/bin/../../src/phobos/std/traits.d(855): static assert  (!isStaticArray!(const(int)[])) is not evaluatable at compile time
$

Interestingly, on Fedora 10, I can recompile dmd and actually use it.

What should I do?

== Quote from Georg Wrede (georg.wrede@iki.fi)'s article
> I wanted to use dmd at another site, so I took my laptop and the latest
> dmd 2 zip.
> All went well, till I ran dmd, and got an error message about it needing
> a newer libc, I had only libc-2.3.5.so on a Fedora version from 2005.
> I thought some expletives about software vendors always compiling their
> products on the absolutely latest OS version, thus introducing
> gratuitous dependencies on brand-new libraries, where most often they
> could compile with a 5 year old version, and make clients happy.
> But, thanks to Walter, /I had the source/, so I compiled dmd from
> scratch. I got a surprise when I tried to use it. Errors I can't figure out:
> $ cat foo.d
> import std.stdio;
> void main(){}
> $ dmd foo.d
> /home/georg/lang/d/dmd/linux/bin/../../src/phobos/std/traits.d(855):
> template instance isStaticArray!(const(int)[]) does not match template
> declaration isStaticArray(T : U[N],U,uint N)
> /home/georg/lang/d/dmd/linux/bin/../../src/phobos/std/traits.d(855):
> Error: expression isStaticArray!(const(int)[]) of type void does not
> have a boolean value
> /home/georg/lang/d/dmd/linux/bin/../../src/phobos/std/traits.d(855):
> static assert  (!isStaticArray!(const(int)[])) is not evaluatable at
> compile time

This might be obvious to you depending on how much you've been reading these newsgroups lately, but double check to make sure you've wiped all the old src stuff from previous releases.  Also, make sure that you put the resulting dmd binary in dmd/linux/bin/ so all the libraries and stuff are where dmd expects them to be.

Oh yeah, and Walter, thank you for the opensource backend is an absolute godsend.
 I encountered the same problem a while back w/ GLIBC, and as a matter of fact
just a few hours ago, I got DMD to compile w/ this ancient GLIBC version and run
on some ancient Linux distro.  However, given that DMD seems to work on ancient
GLIBC, it might make sense to distribute the prebuilt binaries against an older
version.  As far as I can tell they're forward compatible.  Around here we have a
zillion computers, some with ancient Linux distros and some with newer ones, and
it seems like if you compile DMD on an ancient distro it will work on a newer
(modulo not having 32-bit pthreads present, etc), but not the other way around.

dsimcha wrote:
> Oh yeah, and Walter, thank you for the opensource backend is an absolute godsend.
>  I encountered the same problem a while back w/ GLIBC, and as a matter of fact
> just a few hours ago, I got DMD to compile w/ this ancient GLIBC version and run
> on some ancient Linux distro.  However, given that DMD seems to work on ancient
> GLIBC, it might make sense to distribute the prebuilt binaries against an older
> version.  As far as I can tell they're forward compatible.  Around here we have a
> zillion computers, some with ancient Linux distros and some with newer ones, and
> it seems like if you compile DMD on an ancient distro it will work on a newer
> (modulo not having 32-bit pthreads present, etc), but not the other way around.

When I compile dmd with the old lib, I tick off 50% of the linux people who don't have the old .so installed. When I compile it with the new lib, I tick off the other 50% who don't have the new one installed.

Walter Bright wrote:
> When I compile dmd with the old lib, I tick off 50% of the linux people who don't have the old .so installed. When I compile it with the new lib, I tick off the other 50% who don't have the new one installed.

That's one reason why I haven't been too interested in distributing phobos as a shared library.

Walter Bright wrote:
> Walter Bright wrote:
>> When I compile dmd with the old lib, I tick off 50% of the linux people who don't have the old .so installed. When I compile it with the new lib, I tick off the other 50% who don't have the new one installed.

I hope that was some time ago. If there's no solution, I can live with that.

Seems upgrading libc is non-trivial. Now I know.

I was *intrigued* by the error messages, because I wasn't expecting anything such. I would've thought that either the source works, or then not. What's "wrong"?

> That's one reason why I haven't been too interested in distributing phobos as a shared library.

Georg Wrede wrote:
> Walter Bright wrote:
>> Walter Bright wrote:
>>> When I compile dmd with the old lib, I tick off 50% of the linux people who don't have the old .so installed. When I compile it with the new lib, I tick off the other 50% who don't have the new one installed.
> 
> I hope that was some time ago. If there's no solution, I can live with that.
> 
> Seems upgrading libc is non-trivial. Now I know.
> 
> I was *intrigued* by the error messages, because I wasn't expecting anything such. I would've thought that either the source works, or then not. What's "wrong"?

The source works just fine. The binaries don't. The new lib distros don't include the old lib, and vice versa. Often the missing lib isn't available. It's an ongoing nuisance.

It isn't like Windows, where the basic api's have been unchanged for nearly 20 years.

Mac OSX is the worst of the lot, there you get a "bus error" if you build for 10.5 and run it on 10.4.

On 2009-03-11 04:50:37 -0400, Walter Bright <newshound1@digitalmars.com> said:

> The source works just fine. The binaries don't. The new lib distros don't include the old lib, and vice versa. Often the missing lib isn't available. It's an ongoing nuisance.
> 
> It isn't like Windows, where the basic api's have been unchanged for nearly 20 years.
> 
> Mac OSX is the worst of the lot, there you get a "bus error" if you build for 10.5 and run it on 10.4.

Yeah, the error message is bad. But on Mac OS X if you build for 10.4 (either by building on 10.4 or using the 10.4 SDK bundled with Xcode) it'll be forward-compatible with the newer versions of Mac OS X yet to come. For instance, I can run apps compiled on 10.0 quite well on 10.5, with no tweaking at all. Seems on Linux if you choose the old lib it won't run on the newer distos. That looks worse to me.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On Wed, Mar 11, 2009 at 12:56 PM, Michel Fortin <michel.fortin@michelf.com> wrote:
> On 2009-03-11 04:50:37 -0400, Walter Bright <newshound1@digitalmars.com> said:
>
>> The source works just fine. The binaries don't. The new lib distros don't include the old lib, and vice versa. Often the missing lib isn't available. It's an ongoing nuisance.
>>
>> It isn't like Windows, where the basic api's have been unchanged for nearly 20 years.
>>
>> Mac OSX is the worst of the lot, there you get a "bus error" if you build for 10.5 and run it on 10.4.
>
> Yeah, the error message is bad. But on Mac OS X if you build for 10.4 (either by building on 10.4 or using the 10.4 SDK bundled with Xcode) it'll be forward-compatible with the newer versions of Mac OS X yet to come. For instance, I can run apps compiled on 10.0 quite well on 10.5, with no tweaking at all. Seems on Linux if you choose the old lib it won't run on the newer distos. That looks worse to me.

This is usually not a problem as most linux software is free (as in freedom) and has open source code though.

Commercial applications can simply provide multiple binaries. Just like the situation is getting for XP/Vista as well (I know, it's only really games, and it's not really the same situation, but anyway ...)

DMD source code being available is a good start, but as I understand it, Linux distributions are still not allowed to redistribute it ? Or binaries of a modified source build ?

-Tomas

>
> --
> Michel Fortin
> michel.fortin@michelf.com
> http://michelf.com/
>
>

On Wed, 11 Mar 2009 15:14:44 +0300, Tomas Lindquist Olsen <tomas.l.olsen@gmail.com> wrote:

> On Wed, Mar 11, 2009 at 12:56 PM, Michel Fortin
> <michel.fortin@michelf.com> wrote:
>> On 2009-03-11 04:50:37 -0400, Walter Bright <newshound1@digitalmars.com>
>> said:
>>
>>> The source works just fine. The binaries don't. The new lib distros don't
>>> include the old lib, and vice versa. Often the missing lib isn't available.
>>> It's an ongoing nuisance.
>>>
>>> It isn't like Windows, where the basic api's have been unchanged for
>>> nearly 20 years.
>>>
>>> Mac OSX is the worst of the lot, there you get a "bus error" if you build
>>> for 10.5 and run it on 10.4.
>>
>> Yeah, the error message is bad. But on Mac OS X if you build for 10.4
>> (either by building on 10.4 or using the 10.4 SDK bundled with Xcode) it'll
>> be forward-compatible with the newer versions of Mac OS X yet to come. For
>> instance, I can run apps compiled on 10.0 quite well on 10.5, with no
>> tweaking at all. Seems on Linux if you choose the old lib it won't run on
>> the newer distos. That looks worse to me.
>
> This is usually not a problem as most linux software is free (as in
> freedom) and has open source code though.
>
> Commercial applications can simply provide multiple binaries. Just
> like the situation is getting for XP/Vista as well (I know, it's only
> really games, and it's not really the same situation, but anyway ...)
>

It's more like x86/x86_64 situation.

> DMD source code being available is a good start, but as I understand
> it, Linux distributions are still not allowed to redistribute it ? Or
> binaries of a modified source build ?
>
> -Tomas
>

Is there a need for that? Gentoo ebuild can automatically fetch source code from digitalmars.com and compile the binary (given the ebuild, of course), and I believe other distros can do the same.

>>
>> --
>> Michel Fortin
>> michel.fortin@michelf.com
>> http://michelf.com/
>>
>>

Walter Bright wrote:
>> Seems upgrading libc is non-trivial. Now I know.
>>
>> I was *intrigued* by the error messages, because I wasn't expecting anything such. I would've thought that either the source works, or then not. What's "wrong"?
> 
> The source works just fine. The binaries don't.

So, if I compile dmd without errors, then, depending on the particular OS version, the internal logic of dmd becomes different?