www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Binary compatibility on Linux

reply Jacob Carlborg <doob me.com> writes:
What's the best way to achieve binary compatibility on Linux? For 
example, if I compile an application on, say Ubuntu 12.04, it will most 
likely not run on any older versions of Ubuntu but it will run on future 
versions.

My current approach to solve this is to compile the application in the 
oldest version of Ubuntu I can find, in this case 6.x. This is starting 
to get a bit problematic:

* The integration with VirtuaBox (I'm running Ubuntu as a guest) is 
pretty bad
* DMD won't run of out of the box, I need to compile it. This is also 
making DVM basically useless
* I can't clone the dlang repositories due to having a very old version 
of git installed
* I can't compile git, I haven't investigated in why but probably due to 
the system is too old

Is there some compiler/linker flags I can use when building to make the 
executable compatibility with older versions of Linux?

Or is there a better way to solve this?

-- 
/Jacob Carlborg
Nov 10 2012
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 10.11.2012 16:40, schrieb Jacob Carlborg:

 What's the best way to achieve binary compatibility on Linux? For
 example, if I compile an application on, say Ubuntu 12.04, it will most
 likely not run on any older versions of Ubuntu but it will run on future
 versions.

 My current approach to solve this is to compile the application in the
 oldest version of Ubuntu I can find, in this case 6.x. This is starting
 to get a bit problematic:

 * The integration with VirtuaBox (I'm running Ubuntu as a guest) is
 pretty bad
 * DMD won't run of out of the box, I need to compile it. This is also
 making DVM basically useless
 * I can't clone the dlang repositories due to having a very old version
 of git installed
 * I can't compile git, I haven't investigated in why but probably due to
 the system is too old

 Is there some compiler/linker flags I can use when building to make the
 executable compatibility with older versions of Linux?

 Or is there a better way to solve this?


I guess the right answer is to have everything compiled statically, 
especially if you need compatibility across distributions.

--
Paulo
Nov 10 2012
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 10 November 2012 17:39, Paulo Pinto <pjmlp progtools.org> wrote:

 Am 10.11.2012 16:40, schrieb Jacob Carlborg:


 What's the best way to achieve binary compatibility on Linux? For
 example, if I compile an application on, say Ubuntu 12.04, it will most
 likely not run on any older versions of Ubuntu but it will run on future
 versions.

 My current approach to solve this is to compile the application in the
 oldest version of Ubuntu I can find, in this case 6.x. This is starting
 to get a bit problematic:

 * The integration with VirtuaBox (I'm running Ubuntu as a guest) is
 pretty bad
 * DMD won't run of out of the box, I need to compile it. This is also
 making DVM basically useless
 * I can't clone the dlang repositories due to having a very old version
 of git installed
 * I can't compile git, I haven't investigated in why but probably due to
 the system is too old

 Is there some compiler/linker flags I can use when building to make the
 executable compatibility with older versions of Linux?

 Or is there a better way to solve this?


 I guess the right answer is to have everything compiled statically,
 especially if you need compatibility across distributions.

 --
 Paulo


Or ship the binary with it's dependencies all together as one package.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 10 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-10 18:39, Paulo Pinto wrote:


 I guess the right answer is to have everything compiled statically,
 especially if you need compatibility across distributions.


I just read somewhere that compiling it statically will make it _less_ 
compatible than compiling it dynamically.



-- 
/Jacob Carlborg
Nov 10 2012
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 10.11.2012 19:54, schrieb Jacob Carlborg:

 On 2012-11-10 18:39, Paulo Pinto wrote:


 I guess the right answer is to have everything compiled statically,
 especially if you need compatibility across distributions.


 I just read somewhere that compiling it statically will make it _less_
 compatible than compiling it dynamically.




Oh, the wonder of Linux based systems. :(
Nov 10 2012
prev sibling next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Sat, 10 Nov 2012 16:40:37 +0100
schrieb Jacob Carlborg <doob me.com>:


 What's the best way to achieve binary compatibility on Linux? For 
 example, if I compile an application on, say Ubuntu 12.04, it will
 most likely not run on any older versions of Ubuntu but it will run
 on future versions.
 
 My current approach to solve this is to compile the application in
 the oldest version of Ubuntu I can find, in this case 6.x. This is
 starting to get a bit problematic:
 
 * The integration with VirtuaBox (I'm running Ubuntu as a guest) is 
 pretty bad
 * DMD won't run of out of the box, I need to compile it. This is also 
 making DVM basically useless
 * I can't clone the dlang repositories due to having a very old
 version of git installed
 * I can't compile git, I haven't investigated in why but probably due
 to the system is too old
 
 Is there some compiler/linker flags I can use when building to make
 the executable compatibility with older versions of Linux?
 
 Or is there a better way to solve this?
 


crosstool-NG has a nice option "Oldest supported ABI" where you
can enter an old GLIBC version and the compiler will generate
executables compatible with this version (although it still uses a
recent glibc). I have no idea how this works, but that's the best
solution I have seen so far. (crosstool also has an option "Disable
symbols versioning" which completely disables versioning. quite cool).

Here are some links which might help:
http://sourceware.org/ml/libc-help/2011-04/msg00032.html
http://www.trevorpounds.com/blog/?tag=symbol-versioning
Nov 10 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-10 19:54, Johannes Pfau wrote:


 crosstool-NG has a nice option "Oldest supported ABI" where you
 can enter an old GLIBC version and the compiler will generate
 executables compatible with this version (although it still uses a
 recent glibc). I have no idea how this works, but that's the best
 solution I have seen so far. (crosstool also has an option "Disable
 symbols versioning" which completely disables versioning. quite cool).

 Here are some links which might help:
 http://sourceware.org/ml/libc-help/2011-04/msg00032.html
 http://www.trevorpounds.com/blog/?tag=symbol-versioning


I got the last link from someone in the D IRC channel. I just don't know 
how to do that with D.

-- 
/Jacob Carlborg
Nov 10 2012
prev sibling next sibling parent reply Jordi Sayol <g.sayol yahoo.es> writes:
Al 10/11/12 16:40, En/na Jacob Carlborg ha escrit:

 What's the best way to achieve binary compatibility on Linux? For example, if
I compile an application on, say Ubuntu 12.04, it will most likely not run on
any older versions of Ubuntu but it will run on future versions.
 
 My current approach to solve this is to compile the application in the oldest
version of Ubuntu I can find, in this case 6.x. This is starting to get a bit
problematic:
 
 * The integration with VirtuaBox (I'm running Ubuntu as a guest) is pretty bad
 * DMD won't run of out of the box, I need to compile it. This is also making
DVM basically useless
 * I can't clone the dlang repositories due to having a very old version of git
installed
 * I can't compile git, I haven't investigated in why but probably due to the
system is too old
 
 Is there some compiler/linker flags I can use when building to make the
executable compatibility with older versions of Linux?
 
 Or is there a better way to solve this?
 


Ubuntu 10.04.4 LTS is old enough?
You can install/run dmd out of the box on it just installing the appropriate
deb package.

-- 
Jordi Sayol
Nov 10 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-10 19:49, Jordi Sayol wrote:


 Ubuntu 10.04.4 LTS is old enough?


I have no idea. I don't know how often people update their Linux systems 
and how compatible different distributions are. Sine I'm not using Linux 
as my primary platform I was hoping someone else could answer this.

What is the oldest system I need to reasonably support? I'm mostly 
talking about tools and libraries for the D community here.

-- 
/Jacob Carlborg
Nov 10 2012
next sibling parent reply 1100110 <0b1100110 gmail.com> writes:
On Sat, 10 Nov 2012 13:01:27 -0600, Jacob Carlborg <doob me.com> wrote:


 On 2012-11-10 19:49, Jordi Sayol wrote:


 Ubuntu 10.04.4 LTS is old enough?


 I have no idea. I don't know how often people update their Linux systems  
 and how compatible different distributions are. Sine I'm not using Linux  
 as my primary platform I was hoping someone else could answer this.

 What is the oldest system I need to reasonably support? I'm mostly  
 talking about tools and libraries for the D community here.


Oldest system to reasonably support?  I would say Debian Stable.
It is used on a lot of server systems and isn't *too* far behind/old.

If you need newer versions of packages, debian has its testing and  
experimental branches.

I don't remember if they still are, but Ubuntu used to take a snapshot of  
Debian Sid to base its packages on.
Linux Mint Debian gets its packages from debian testing I believe.

The point I'm making is that Debian is pretty much the upstream repo.  You  
can go as far as to test versions that haven't made it into Ubuntu or Mint  
yet.

If people are using older versions than Debian Stable, then you should  
probably forget about them.
Either they will cherry-pick the versions they need, or they are not  
interested in anything new and untested.

Just my two cents as an ex server admin.
Nov 10 2012
next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Saturday, 10 November 2012 at 19:15:28 UTC, 1100110 wrote:

 If people are using older versions than Debian Stable, then you 
 should probably forget about them.
 Either they will cherry-pick the versions they need, or they 
 are not interested in anything new and untested.

 Just my two cents as an ex server admin.


This seems like a reasonable policy to me as well.

David
Nov 10 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-10 20:10, 1100110 wrote:


 Oldest system to reasonably support?  I would say Debian Stable.
 It is used on a lot of server systems and isn't *too* far behind/old.


How compatible is Debian with non-debian based distributions?

-- 
/Jacob Carlborg
Nov 11 2012
parent reply 1100110 <0b1100110 gmail.com> writes:
On Sun, 11 Nov 2012 04:45:48 -0600, Jacob Carlborg <doob me.com> wrote:


 On 2012-11-10 20:10, 1100110 wrote:


 Oldest system to reasonably support?  I would say Debian Stable.
 It is used on a lot of server systems and isn't *too* far behind/old.


 How compatible is Debian with non-debian based distributions?


I've used alien a fair number of times, and its usually "just worked."
Here is an FAQ:  
http://www.debian.org/doc/manuals/debian-faq/ch-compat.en.html
That link provides a lot of info.

Honestly, unless Ubuntu has done something really weird, Debian should be  
just as compatible with non-Debian distros as Ubuntu is.  Give me a solid  
example of what you mean and I'll take a closer look.

Ubuntu has a Debian-for-Ubuntu-Devs page.  
https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers
That should explain something at least.

How does Debian Stable compare to Ubuntu 8.04(Hardy Heron) LTS which loses  
support in April?
I'm not entirely sure.  http://packages.ubuntu.com/hardy/   
http://packages.debian.org/stable/
Nov 11 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-11 23:30, 1100110 wrote:


 I've used alien a fair number of times, and its usually "just worked."
 Here is an FAQ:
 http://www.debian.org/doc/manuals/debian-faq/ch-compat.en.html
 That link provides a lot of info.

 Honestly, unless Ubuntu has done something really weird, Debian should
 be just as compatible with non-Debian distros as Ubuntu is.  Give me a
 solid example of what you mean and I'll take a closer look.


I'm not saying it's incompatible, I'm asking :) BTW, I actually don't 
know how compatible Ubuntu either.


 Ubuntu has a Debian-for-Ubuntu-Devs page.
 https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers
 That should explain something at least.


I guess I'll to take a look at that page.


 How does Debian Stable compare to Ubuntu 8.04(Hardy Heron) LTS which
 loses support in April?
 I'm not entirely sure.  http://packages.ubuntu.com/hardy/
 http://packages.debian.org/stable/


As I understand it Debian is a more stable distribution and Ubuntu is a 
faster moving target. The question is how much faster. Would Ubuntu LTS 
be more ahead of compared to the latest stable Debian.

-- 
/Jacob Carlborg
Nov 11 2012
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 12 November 2012 at 07:22:04 UTC, Jacob Carlborg wrote:


 As I understand it Debian is a more stable distribution and 
 Ubuntu is a faster moving target. The question is how much 
 faster. Would Ubuntu LTS be more ahead of compared to the 
 latest stable Debian.


Debian testing is a rolling distribution, so it is always in an 
unstable state. Debian stable is, as it says, stable. To answer 
your question, just look at what debain version the particular 
ubuntu LTS version is based on.

To be honest, unless you're going to package all your 
dependancies along with the download, then you have to go down 
one of two routes: source distribution with a nice simple build 
procedure or making packages for the main distributions. I would 
recommend doing both.

Look at it this way: the sort of people who aren't using a debian 
or fedora based distro aren't going to be phased by building from 
source (as a matter of fact they might prefer it).
If you provide packages for debian and fedora and a source 
distribution as a fallback then you've covered the vast majority 
of your bases, allowing less advanced users to use package 
managers and letting the wild-west fringe distro people do 
whatever they want.
Nov 14 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-14 19:20, John Colvin wrote:


 Debian testing is a rolling distribution, so it is always in an unstable
 state. Debian stable is, as it says, stable. To answer your question,
 just look at what debain version the particular ubuntu LTS version is
 based on.


Good point, how can I do that?


 To be honest, unless you're going to package all your dependancies along
 with the download, then you have to go down one of two routes: source
 distribution with a nice simple build procedure or making packages for
 the main distributions. I would recommend doing both.


I do provide source distribution. Not much of distribution, it's always 
available on Github. But I have one tool, DVM, which is a tool for 
installing D compilers and it's also written in D. It's a bit of a 
chicken-and-egg-problem. Sure you can get D compiler in other ways. But 
I think this tool in particular is very convenient to have available as 
a pre-built executable.

A read a bit about creating packages for Debian, it seemed complicated 
and that I need to use stupid tools like Make. I hate Make.


 Look at it this way: the sort of people who aren't using a debian or
 fedora based distro aren't going to be phased by building from source
 (as a matter of fact they might prefer it).
 If you provide packages for debian and fedora and a source distribution
 as a fallback then you've covered the vast majority of your bases,
 allowing less advanced users to use package managers and letting the
 wild-west fringe distro people do whatever they want.



-- 
/Jacob Carlborg
Nov 14 2012
parent reply Thomas Koch <thomas koch.ro> writes:
Jacob Carlborg wrote:


 On 2012-11-14 19:20, John Colvin wrote:
 

 Debian testing is a rolling distribution, so it is always in an unstable
 state. Debian stable is, as it says, stable. To answer your question,
 just look at what debain version the particular ubuntu LTS version is
 based on.


 
 Good point, how can I do that?


Ubuntu versions are not based on Debian _releases_. Ubuntu has an ever 
repeating development circle of half a year. At the beginning of the circle 
they take a snapshot of Debian unstable[1] and in the next months they mold 
this snapshot in an ubuntu release.

[1] http://www.debian.org/releases

To answer your question: There might be moments, directly after the release 
of a Debian stable version, when Ubuntu LTS is older then Debian. And after 
an LTS release the current Debian stable is surely older.
 

 To be honest, unless you're going to package all your dependancies along
 with the download, then you have to go down one of two routes: source
 distribution with a nice simple build procedure or making packages for
 the main distributions. I would recommend doing both.


 
 I do provide source distribution. Not much of distribution, it's always
 available on Github. But I have one tool, DVM, which is a tool for
 installing D compilers and it's also written in D. It's a bit of a
 chicken-and-egg-problem. Sure you can get D compiler in other ways. But
 I think this tool in particular is very convenient to have available as
 a pre-built executable.
 
 A read a bit about creating packages for Debian, it seemed complicated
 and that I need to use stupid tools like Make. I hate Make.


You're right about make. However the Makefiles that one needs today for 
Debian packages are so trivial that it's not worth to worry about it. The 
most basic debian/rules (which is a Makefile) looks like:


               %:
                       dh $ 

You only need to add additional targets if you want to override default 
actions. In that case you usually add simple targets with a few lines.

We could switch from Makefiles to something else but it's simply not worth 
the effort.

But after all you don't need to do the Debian packaging yourself. It's even 
a bit infamous if upstream is also the maintainer of the Debian package for 
different reasons. Just be a good upstream[2] and find a Debian maintainer 
who cares about your software. The same thing for Fedora.

[2] wiki.debian.org/UpstreamGuide

Regards, Thomas Koch
Nov 14 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-15 08:51, Thomas Koch wrote:


 You're right about make. However the Makefiles that one needs today for
 Debian packages are so trivial that it's not worth to worry about it. The
 most basic debian/rules (which is a Makefile) looks like:


                 %:
                         dh $ 

 You only need to add additional targets if you want to override default
 actions. In that case you usually add simple targets with a few lines.

 We could switch from Makefiles to something else but it's simply not worth
 the effort.


Well, I simply don't think Makefiles are worth the effort.


 But after all you don't need to do the Debian packaging yourself. It's even
 a bit infamous if upstream is also the maintainer of the Debian package for
 different reasons. Just be a good upstream[2] and find a Debian maintainer
 who cares about your software. The same thing for Fedora.


It's not thinking about making the actual Debian package, I was more 
thinking of building the actual software.


 [2] wiki.debian.org/UpstreamGuide


I've read that page and from my understanding they prefer to use "make":

"Please don't use SCons"
"Using waf as build system is discouraged"


-- 
/Jacob Carlborg
Nov 15 2012
parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2012-11-15 at 10:35 +0100, Jacob Carlborg wrote:
[=E2=80=A6]

 [2] wiki.debian.org/UpstreamGuide


=20
 I've read that page and from my understanding they prefer to use "make":
=20
 "Please don't use SCons"
 "Using waf as build system is discouraged"


Comments made by people who are steeped in Autoconf/Automake and haven't
actually used more modern systems such as SCons or Waf.

The comments on the website are almost, but not quite, totally wrong on
all important points.
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 15 2012
next sibling parent reply Thomas Koch <thomas koch.ro> writes:
Russel Winder wrote:


 On Thu, 2012-11-15 at 10:35 +0100, Jacob Carlborg wrote:
 […]

 [2] wiki.debian.org/UpstreamGuide


 
 I've read that page and from my understanding they prefer to use "make":
 
 "Please don't use SCons"
 "Using waf as build system is discouraged"


 
 Comments made by people who are steeped in Autoconf/Automake and haven't
 actually used more modern systems such as SCons or Waf.
 
 The comments on the website are almost, but not quite, totally wrong on
 all important points.


The "website" is a wiki site edited by many people over a longer time 
period. If you found points you disagree with I'd love to see a comment 
added.

I for example don't know either SCons or Waf. Maybe the information in our 
UpstreamGuide is not up to date anymore.

Have you found more issues with the text? It would be interesting for us to 
listen to the opinions of non-debian members.

Regards, Thomas Koch
Nov 15 2012
parent reply Russel Winder <russel winder.org.uk> writes:
[[I suspect this is getting way off-topic for this list, so if
instructed to take it elsewhere will be happy to do so as long as
elsewhere is defined.]]

On Thu, 2012-11-15 at 17:52 +0100, Thomas Koch wrote:
[=E2=80=A6]

 The "website" is a wiki site edited by many people over a longer time=20
 period. If you found points you disagree with I'd love to see a comment=


=20

 added.


"Please don't use SCons: we will have to re-implement many standard
features of autoconf/automake, including DESTDIR, out of tree builds,
cleaning and more."

This just shows that the Debian system is so rooted in Autoconf/Automake
that the mindset is to oppose anything that isn't.  SCons supports out
of tree builds far better than Autoconf/Automake.  SCons supports
cleaning far better than Autoconf/Automake, just differently. What is
this "more"? Why is DESTDIR so important? SCons has good ways of doing
installation, just differently.

The problem here is that Debian gives no guidance to people who want to
use SCons how to write their SCons builds to be harmonious with the
Debian way of doing things. Instead the Debian system says "we are
Autoconf/Autotools, so don't use SCons".=20


"Using waf as build system is discouraged. One of the reasons is the
recommendation to ship a waf executable in every single package using
it, instead of using a system wide one. Also note that just shipping the
waf executable (which contains a binary blob) is considered to be not
complient with the Debian Free Software guidelines by the FTP Team.

to avoid it, if you have to use waf."

It is true that Thomas pushes the "carry the build system with the
project" line. In fact Gradle has done something along these lines as
well. Indeed SCons supports this way of working. In a global context, it
is a very good idea, even if it is conflict with the Debian way of
working.  But like SCons, Waf works very well with an installed Waf, the
project supplied Waf can be ignored.  The Waf executable is not a binary
blob really, it is just an encoded source distribution which has to be
decoded. If the people had investigated properly this comment would just
not have been made. Actually the comments on the indicated issue explain
this very clearly.  Sadly other comments wilfully misrepresent the
status quo.


 I for example don't know either SCons or Waf. Maybe the information in ou=


r=20

 UpstreamGuide is not up to date anymore.


To be honest, the comments never were reasonable, they were founded on
prejudice and lack of research.  If the instructions were "We like
Autotools/Automake and are not prepared to work with anything else." it
would be more acceptable as being opinionated, honest, and a statement
to people how Debian worked. This would be far more acceptable/better
than the FUD that is there.


 Have you found more issues with the text? It would be interesting for us =


to=20

 listen to the opinions of non-debian members.


I am a Debian Unstable user and fan. I hate Autotools/Automake.
Therefore I do not get involved in building packages for Debian, I am
just a freeloading user, total fretard ;-) I have though been known to
build packages and put them in my own repository. I'm sometimes selfish
like that :-)=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 15 2012
parent Thomas Koch <thomas koch.ro> writes:
Russel Winder wrote:


 [[I suspect this is getting way off-topic for this list, so if
 instructed to take it elsewhere will be happy to do so as long as
 elsewhere is defined.]]


I added your comments and a remark about the role of make in Debian:
http://wiki.debian.org/UpstreamGuide?action=diff&rev1=58&rev2=59

I'd invite you to continue this discussion on debian-devel lists.debian.org 
(no subscription required).

The UpstreamGuide is an important document for the "public relations" of 
Debian, so I'd like to get it right.

Regards, Thomas Koch
Nov 16 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-15 17:23, Russel Winder wrote:


 Comments made by people who are steeped in Autoconf/Automake and haven't
 actually used more modern systems such as SCons or Waf.

 The comments on the website are almost, but not quite, totally wrong on
 all important points.


I'm not saying that they're right or wrong. I'm saying that they're 
there and it's obviously someones opinion. It also indicates that 
something that doesn't use Makefiles is not accepted or harder to get 
accepted.

-- 
/Jacob Carlborg
Nov 15 2012
parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2012-11-15 at 20:42 +0100, Jacob Carlborg wrote:
[=E2=80=A6]

 I'm not saying that they're right or wrong. I'm saying that they're=20
 there and it's obviously someones opinion. It also indicates that=20
 something that doesn't use Makefiles is not accepted or harder to get=20
 accepted.


I just submitted a email on this which I think answers the point. I
worry that it is way off-topic for this list though. The summary is that
Debian is Autotools/Automake focussed and any other build is a problem
for them. I think this is sad, but it is Debian's privilege to be
dictatorial on this for the Debian repository.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 15 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-10 20:10, 1100110 wrote:


 Oldest system to reasonably support?  I would say Debian Stable.
 It is used on a lot of server systems and isn't *too* far behind/old.


How would Debian Stable compare to, say, a five year old Ubuntu LTS that 
is still supported?

-- 
/Jacob Carlborg
Nov 11 2012
prev sibling parent reply Robert <jfanatiker gmx.at> writes:
I would say supporting distributions which are no longer supported by
the distributions itself is of very little value. So for Ubuntu the last
still supported LTS version should be old enough.

I think virtually nobody is using anything older, especially not 06.XX!
And if they do, then they will have a whole bunch of other problems than
not being able to use your program.

Best regards,

Robert

On Sat, 2012-11-10 at 20:01 +0100, Jacob Carlborg wrote:

 On 2012-11-10 19:49, Jordi Sayol wrote:
 

 Ubuntu 10.04.4 LTS is old enough?


 
 I have no idea. I don't know how often people update their Linux systems 
 and how compatible different distributions are. Sine I'm not using Linux 
 as my primary platform I was hoping someone else could answer this.
 
 What is the oldest system I need to reasonably support? I'm mostly 
 talking about tools and libraries for the D community here.
Nov 10 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-10 20:17, Robert wrote:

 I would say supporting distributions which are no longer supported by
 the distributions itself is of very little value. So for Ubuntu the last
 still supported LTS version should be old enough.

 I think virtually nobody is using anything older, especially not 06.XX!
 And if they do, then they will have a whole bunch of other problems than
 not being able to use your program.


I just picked the 6.x version to be sure it was compatible with 
everything else.

You say the latest LTS, but the LTS are supported for five years. Don't 
they release new LTS more often than that? According to this 
https://wiki.ubuntu.com/LTS They release a new LTS every two years and 
they're supported for five years.

If I pick Ubuntu 12.04, which is the latest LTS, they still support 
10.04 until 2013.

-- 
/Jacob Carlborg
Nov 10 2012
next sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
Al 10/11/12 21:18, En/na Jacob Carlborg ha escrit:

 On 2012-11-10 20:17, Robert wrote:

 I would say supporting distributions which are no longer supported by
 the distributions itself is of very little value. So for Ubuntu the last
 still supported LTS version should be old enough.

 I think virtually nobody is using anything older, especially not 06.XX!
 And if they do, then they will have a whole bunch of other problems than
 not being able to use your program.


 
 I just picked the 6.x version to be sure it was compatible with everything
else.
 
 You say the latest LTS, but the LTS are supported for five years. Don't they
release new LTS more often than that? According to this
https://wiki.ubuntu.com/LTS They release a new LTS every two years and they're
supported for five years.
 
 If I pick Ubuntu 12.04, which is the latest LTS, they still support 10.04
until 2013.
 



From Ubuntu 12.04 (April 2012), LTS has 5 years of support for Desktop and
server versions. Before this, LTS for Desktop has 3 years support, so the last
Ubuntu Desktop still supported is 10.04 (April 2010) and will finish in April
2013.


-- 
Jordi Sayol
Nov 10 2012
prev sibling next sibling parent reply eskimo <jfanatiker gmx.at> writes:
 
 You say the latest LTS, but the LTS are supported for five years. Don't 
 they release new LTS more often than that? According to this 
 https://wiki.ubuntu.com/LTS They release a new LTS every two years and 
 they're supported for five years.


I am sorry. I haven't quite said what I meant. I meant: The oldest still
supported LTS of course :-) 

Also there are very few desktop users using such an old version, so if
you don't target server systems, you might even relax your requirements
further. But with the oldest still supported LTS release you are pretty
much on the safe side. 

Best regards,

Robert
Nov 10 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-10 22:14, eskimo wrote:


 I am sorry. I haven't quite said what I meant. I meant: The oldest still
 supported LTS of course :-)


That makes more sense.

-- 
/Jacob Carlborg
Nov 11 2012
prev sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
From Ubuntu 12.04 (April 2012), LTS has 5 years of support for Desktop and
server versions. Before this, LTS for Desktop has 3 years support, so the last
Ubuntu Desktop still supported is 10.04 (April 2010) and will finish in April
2013.
 


s/last/oldest/

-- 
Jordi Sayol
Nov 10 2012
prev sibling parent reply Thomas Koch <thomas koch.ro> writes:
Jacob Carlborg wrote:


 What's the best way to achieve binary compatibility on Linux? For
 example, if I compile an application on, say Ubuntu 12.04, it will most
 likely not run on any older versions of Ubuntu but it will run on future
 versions.


The best way is to get your software in the official debian archive. There 
are infrastructure and established workflows to recompile packages for each 
Debian version.
The backports archive contains newer versions of a package for the current 
stable Debian release.

Is the software in question free software? It's not that hard to get 
software in Debian. Have a look at 
http://wiki.debian.org/UpstreamGuide

Regards, Thomas Koch
Nov 11 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-11 10:30, Thomas Koch wrote:


 The best way is to get your software in the official debian archive. There
 are infrastructure and established workflows to recompile packages for each
 Debian version.
 The backports archive contains newer versions of a package for the current
 stable Debian release.


I don't want to limit myself to just the debian based package mangers. I 
want my tools to be available/usable on all distributions.

-- 
/Jacob Carlborg
Nov 11 2012
parent reply Thomas Koch <thomas koch.ro> writes:
Jacob Carlborg wrote:


 On 2012-11-11 10:30, Thomas Koch wrote:
 

 The best way is to get your software in the official debian archive.
 There are infrastructure and established workflows to recompile packages
 for each Debian version.
 The backports archive contains newer versions of a package for the
 current stable Debian release.


 
 I don't want to limit myself to just the debian based package mangers. I
 want my tools to be available/usable on all distributions.


If your package is in Debian then it is automatically also in Ubuntu, Mint, 
Xandros, Univention, Aptosid, Knoppix and a few douzend more distributions 
which are all derivatives of Debian:

http://wiki.debian.org/Derivatives/Census
http://www.debian.org/misc/children-distros

Roughly the other half(?) of the linux universe is based on Fedora, e.g. 
CentOS, Red Hat:
https://fedoraproject.org/wiki/Derived_distributions

So by getting your package in the archives of Debian and Fedora, you should 
serve the large majority of linux users.

The Debian wiki has a list of advantages why somebody would want to have his 
software in a distributions archive:
http://wiki.debian.org/AdvantagesForUpstream

Best regards,

Thomas Koch
Nov 11 2012
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 11/11/2012 11:57 AM, Thomas Koch wrote:

 So by getting your package in the archives of Debian and Fedora, you should
 serve the large majority of linux users.


Which is well and good, but doesn't address the problem that software
developers 
face, which is "How can I make directly available binaries of my programs that 
will work for any Linux user?"

It's useful to be able to do that regardless of whether your software is FOSS 
and regardless of whether or not it's in distro repositories, because your 
latest release will always take time to propagate to the distros and because
not 
everyone is comfortable compiling from source.
Nov 11 2012
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 11 Nov 2012 12:45:56 +0100
Joseph Rushton Wakeling <joseph.wakeling webdrake.net> wrote:


 On 11/11/2012 11:57 AM, Thomas Koch wrote:

 So by getting your package in the archives of Debian and Fedora,
 you should serve the large majority of linux users.


 
 Which is well and good, but doesn't address the problem that software
 developers face, which is "How can I make directly available binaries
 of my programs that will work for any Linux user?"
 


I'm not a Linux expert, but I'm fairly certain the answer is "You
can't". Linux is very good at a lot of things, but standardization is
definitely not one of them. Linux is just far too divergent ("herding
cats" comes to mind) for a widely-compatible binary to be realistic.
The best that can be done is make a dead-simple-to-use script to grab
dependencies (isolated from the rest of the system if need be) and
compile.


 It's useful to be able to do that regardless of whether your software
 is FOSS and regardless of whether or not it's in distro repositories,
 because your latest release will always take time to propagate to the
 distros and because not everyone is comfortable compiling from source.
Nov 11 2012
next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 11/11/2012 01:19 PM, Nick Sabalausky wrote:

 I'm not a Linux expert, but I'm fairly certain the answer is "You
 can't". Linux is very good at a lot of things, but standardization is
 definitely not one of them. Linux is just far too divergent ("herding
 cats" comes to mind) for a widely-compatible binary to be realistic.
 The best that can be done is make a dead-simple-to-use script to grab
 dependencies (isolated from the rest of the system if need be) and
 compile.


I think you're most likely right -- at least, it's impossible in the general 
case if not perhaps for a narrow band of widely-used distros.

It's just that I think people were answering a different question from that 
which the OP asked, and I think his actual question deserves a decent answer 
(even if it's a negative one).
Nov 11 2012
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Sun, 2012-11-11 at 07:19 -0500, Nick Sabalausky wrote:
[=E2=80=A6]

 I'm not a Linux expert, but I'm fairly certain the answer is "You
 can't". Linux is very good at a lot of things, but standardization is
 definitely not one of them. Linux is just far too divergent ("herding
 cats" comes to mind) for a widely-compatible binary to be realistic.
 The best that can be done is make a dead-simple-to-use script to grab
 dependencies (isolated from the rest of the system if need be) and
 compile.


[=E2=80=A6]

There is only one Linux, well except that they keep evolving it and
changing the version number. Linux is very standardized in that there is
only one. There is no Linux divergence as there was UNIX divergence.

There are many, many, Linux-based distributions. The compilers vary, the
version of Linux varies, the libraries vary, the packaging system
varies. Binary compatibility across all of these is clearly impossible.
This is not a problem, this is the antithesis of problem, as long as you
allow the platform packagers to package or ship source and a build
specification. Hence aptitude, yum, Waf and such stuff.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 11 2012
prev sibling parent "Kagamin" <spam here.lot> writes:
On Sunday, 11 November 2012 at 11:46:07 UTC, Joseph Rushton 
Wakeling wrote:

 Which is well and good, but doesn't address the problem that 
 software developers face, which is "How can I make directly 
 available binaries of my programs that will work for any Linux 
 user?"


http://en.wikipedia.org/wiki/Open_Build_Service ?
Nov 13 2012