monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] list branches on server?


From: Stephen Leake
Subject: Re: [Monotone-devel] list branches on server?
Date: Sun, 23 Aug 2009 13:41:53 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (windows-nt)

Timothy Brownawell <address@hidden> writes:

> On Sun, 2009-08-23 at 08:20 -0400, Stephen Leake wrote:
>> Timothy Brownawell <address@hidden> writes:
>> 
>> > On Sat, 2009-08-22 at 21:10 -0600, Derek Scherger wrote:
>> >> On Sat, Aug 22, 2009 at 1:59 PM, Timothy Brownawell
>> >> <address@hidden> wrote:
>> >
>> >> 
>> >>           * version skew wrt libstdc++, eg boost and monotone have
>> >>           different ideas of what exactly an std::string looks like
>> >> 
>> >> Fantastic. Can you elaborate on this? I wonder how it's even possible
>> >> when boost is built with the same libstdc++ as monotone on my machine?
>> >
>> > Say your distribution is on gcc 3.4 so that's what boost is compiled
>> > with, and the binary on our site was compiled with 4.0. Or even if you
>> > compile it yourself, but you've installed a later version of gcc than
>> > the version that your distro is currently using.
>> 
>> This applies to any library written in C++, not just Boost. Botan is
>> in C++.
>> 
>> And it applies to C libraries as well, but apparently they are
>> more stable?
>> 
>> In general, anyone experimenting with new versions of compilers has to
>> be aware of such issues, and compile everything consistently.
>
> Yes... I guess what made this a "boost issue" is that boost was the only
> library we didn't bundle at the time.
>
>> The mtn binary for Linux on the mtn website should be more fully
>> described (compiler version, required dynamic library versions), so
>> people can do the right thing with it.
>
> Which would require people to know what gcc version their distro is
> using. This seems reasonable to expect of people coding in C or
> C++, but what of everyone else (particularly if they can't do
> "gcc --version" because it isn't installed)?

Good point.

> Do you know of a way to detect at runtime which compiler version was
> used for the libraries?

No, unless there is a global naming convention on libraries so that
the version numbers are distinct for different compiler versions.
Which seems unlikely.

-- 
-- Stephe




reply via email to

[Prev in Thread] Current Thread [Next in Thread]