> My goal is to create a binary that can be deployed as a simple single
> binary file and does not need any LD_LIBRARY_PATH and its own library
> folder.
>
> This is the ldd output:
[snip]

> For me it looks like all this should be available on recent Linux
> versions.

Not everybody runs a recent Linux version. For instance, there are still
many installations of Red Hat Enterprise Linux version 4 [also CentOS4.]
It is only three years old. It still has 3 months of Full Support,
8 months of Deployment Support, and 4 years of Maintenance Support.

The functional capabilities for which libXrandr was designed
are missing from the majority of existing VGA chips/cards and displays.

Many installations lack the libraries libexpat.so.1 and libXau.so.6.

Run "readelf --version-info " to see which GLIBC_* versions
your executables expect. Greater than GLIBC_2.3.2 probably will force you
to distribute libc.so.6 and the other pieces of glibc-2.x.y.

> I tried to link statically against libfreetype, fontconfig, Xrender
> and Xrandr but this seems not to be so easy and not recommended.

You must distribute "private" libraries, and tell the runtime linker
to use them, if you wish to support at least 75% of existing installations.

--

On 28 Feb., 12:14, John Reiser wrote:

>
> > For me it looks like all this should be available on recent Linux
> > versions.
>
> Not everybody runs a recent Linux version. For instance, there are still
> many installations of Red Hat Enterprise Linux version 4 [also CentOS4.]
> It is only three years old. It still has 3 months of Full Support,
> 8 months of Deployment Support, and 4 years of Maintenance Support.

Well but what is the current state for Desktop users?

I'm compiling on Ubunto 6.06 Dapper Drake. I think this should be old
enough for most desktop users.

At least for them who consider purchasing binary Software. I don't
care
about the others.

> The functional capabilities for which libXrandr was designed
> are missing from the majority of existing VGA chips/cards and displays.

Yes. I found out in the meantime that it is best to link statically
against it.
It only depends on libXrender and hopefully the GUI toolkit (i have to
look at this)
will handle a non working libXrandr gracefully.

> Many installations lack the libraries libexpat.so.1 and libXau.so.6.

I used readelf (thanks for the hint) to read what i'm using and this
is only:

0x00000001 (NEEDED) Shared library: [libXft.so.2]
0x00000001 (NEEDED) Shared library: [libX11.so.6]
0x00000001 (NEEDED) Shared library: [libXext.so.
6]
0x00000001 (NEEDED) Shared library:
[libfreetype.so.6]
0x00000001 (NEEDED) Shared library:
[libfontconfig.so.1]
0x00000001 (NEEDED) Shared library:
[libXrender.so.1]
0x00000001 (NEEDED) Shared library: [librt.so.1]
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libcrypt.so.
1]
0x00000001 (NEEDED) Shared library:
[libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.
1]
0x00000001 (NEEDED) Shared library: [libc.so.6]

Luckily all libs are part of the LSB 3.2 Desktop standard. freetype is
using expat and
Xrender needs Xau. So that's not my responsibility.

> Run "readelf --version-info " to see which GLIBC_* versions
> your executables expect. Greater than GLIBC_2.3.2 probably will force you
> to distribute libc.so.6 and the other pieces of glibc-2.x.y.

How can i find out about this. I have to say that MSDN is giving very
good information
about what function is available on what Version. I really miss any
kind of information
about this in the man pages.
As far as know i'm only using posix and bsd functions. But i guess i
need a good
runtime checker. Unfortunately the LSB checker for Ubuntu does not
work and there
is none for 3.2 prepackaged. Well 6.06 is far from being LSB compliant
anyway.

> You must distribute "private" libraries, and tell the runtime linker
> to use them, if you wish to support at least 75% of existing installations.

No. I will never again distribute any private "pthread" or "glibc"
libraries. You only run
into a complete nightmare. My last try was with Mandriva, Red Hat
Fedora 3 and Suse 9.x
and had such terrible results that i was really really disappointed
and stopped working on
the Linux version for a few years.

This is not possible and thats also why LSB forbids to link to any of
the core libraries
statically or do bundle them and also forbids static compiled
programs.

On 28 Feb., 15:28, Bernhard Agthe wrote:
> Hi,
>
> we had the "portable Application" Discussion a few days back. This
> concept is a completely Windows one, as the problems to overcome are
> Windows ones.
> On any Unix variant (which Linux is) you are not even
> guaranteed that the user will use the same Operating System. Your
> application may be run on Ubuntu Linux as well as FreeBSD Unix or
> Solaris - and then on any CPU type these OS run on: 32-bit, 64-bit,
> Intel-Compatible, SPARC, PowerPC, whatever.

ABI is not a windows concept. The commercial Unix variants were
pretty
good about keeping backward compatibility. Unfortunately only Solaris
is of significance here. HP-UX and AIX are pure niche systems.

Also i looked at NetBSD and OpenBSD. Some fundamental software
libraries are not working correct on this systems. So i consider them
also
as freak systems, with OpenBSD in a very very special freak niche. No
need
to support this guys. Also despite all the code reviews for OpenBSD i
find
more and more comparision reports that are all not encouraging to say
that this two BSD's will ever make any sense for the mass market.

What is left is Linux in all its mutations (remember the good funny MS
ads
with mutated pinguins) on i386/amd64, FreeBSD on i386/amd64 and
Solaris
on i386 and Sparc. I would even count Linux on PPC as anything else
then
freak systems. I mean for real world usable Desktop applications (used
at work
not in the geeks private room - i'm also collecting Unix systems but
this does
not mean that i expect any commerical offer for this combinations). On
PPC
you either have to run MacOSX or the system is just too old (the
handfull
of affordable IBM PPC systems on EBay).

Just to clarify. There might be hunderts of usefull combinations
for Servers and Embedded systems. But this is different from my target
market.

> So "portable" in the Unix world refers to a source package which is as
> platform-independent as you can make it. If you don't want to distribute
> your source you can try for Java but then Java can be disassembled easily.

No the LSB is a good step in this direction and i hope that people see
that we
need binary compatibility across the major non geek Desktop
distributions. It's
a pitty to see how less LSB conformance is out there right now
but i don't give up my hope. The topic is just to important.

And as i said, there are only 6 serious combinations left. This should
be handable.

> Sorry, after some really bad experience in the windows world last year,
> I'm rather fed up with that topic...

Well today was only my compilation day, the rest of the week will go
into the other
problem: package systems. This looks to be the next serious problem.

Hi,

we had the "portable Application" Discussion a few days back. This
concept is a completely Windows one, as the problems to overcome are
Windows ones. On any Unix variant (which Linux is) you are not even
guaranteed that the user will use the same Operating System. Your
application may be run on Ubuntu Linux as well as FreeBSD Unix or
Solaris - and then on any CPU type these OS run on: 32-bit, 64-bit,
Intel-Compatible, SPARC, PowerPC, whatever.

So "portable" in the Unix world refers to a source package which is as
platform-independent as you can make it. If you don't want to distribute
your source you can try for Java but then Java can be disassembled easily.

Sorry, after some really bad experience in the windows world last year,
I'm rather fed up with that topic...

Ciao...

> Well but what is the current state for Desktop users?

It is not uncommon for Desktop users to run some applications on a remote
Server, with DISPLAY= pointing back to their desktop. So the software
environment on that server often matters.

> I'm compiling on Ubunto 6.06 Dapper Drake. I think this should be old
> enough for most desktop users.

You say that you are satisfied with Linux Standard Base (LSB) 3.2 Desktop.
Therefore, compile and build the applications using the associated Software
Development Kit (SDK) development environment.

> At least for them who consider purchasing binary Software. I don't
> care about the others.

Then you must be satisfied with the market penetration of LSB 3.2 Desktop.
Fine; just realize that is probably at most 2/3 of the Linux desktops
that will exist by the end of this year.

[snip]
>>Run "readelf --version-info " to see which GLIBC_* versions
>>your executables expect. Greater than GLIBC_2.3.2 probably will force you
>>to distribute libc.so.6 and the other pieces of glibc-2.x.y.
>
>
> How can i find out about this. I have to say that MSDN is giving very
> good information about what function is available on what Version. I really miss
> any kind of information about this in the man pages.

"readelf --version-info /lib/libc.so.6" tells you which versions matter,
and how many symbols belong to each version. "readelf --symbols /lib/libc.so.6"
shows you which symbols have which versions. "readelf --symbols my_app" tells
you which version of which symbols my_app depends on. The ChangeLog of each glibc
release, plus the top-level Versions.def source file within the release, gives
the details. But again, LSB 3.2 Desktop and SDK already have taken care of this.

> As far as know i'm only using posix and bsd functions. But i guess i
> need a good runtime checker.

An application that is built using LSB 3.2 Desktop SDK doesn't need
further checking: it will run in LSB 3.2 Desktop. Regardless, all the checks
can be run statically using readelf. [Except for explicit runtime lookups
which specify a particular symbol version; but anyone clever enough to
use such code already has assumed responsibility for the costs.]

> Unfortunately the LSB checker for Ubuntu does not work and there is none
> for 3.2 prepackaged. Well 6.06 is far from being LSB compliant anyway.

There is the real opportunity. Either live within [and promote] LSB 3.2 Desktop
(both the benefits and the restrictions), or deal with the reality that LSB 3.2
Desktop is one of many environments competing for attention from users,
administrators, and developers.

--

Well, could you do a build for each of the major distros/versions you
want to support? Thats all I can think of.

On 29 Feb., 03:15, shimp wrote:
> Well, could you do a build for each of the major distros/versions you
> want to support? Thats all I can think of.

Well in this case it would be

1) CentOS / Red Hat REL
2) Debian
3) Fedora
4) Gentoo
5) OpenSuse
6) Suse Enterprise
7) Mandriva
8) Ubuntu
9) PCLinuxOS
10) Slackware

Some of them even in two different version numbers. So i would think
about 15 different main stream distros
that people are using for Desktop apps.

I'm not really after installing all this. I will go with a clean LSB
3.2 sandbox build. Installed the latest lsbapp
checker tool and after removing Xcursor and Xrandr extensions i only
have one not supported function call
in the boehm weisser garbage collector.

I will see how this works. My application is shareware so people can
check if it works on there
system anyway before giving me there credit cards.

And then i can only hope the distris stay backward compatible with
there own previous versions.

llothar writes:
> On 28 Feb., 15:28, Bernhard Agthe wrote:

[...]


>> So "portable" in the Unix world refers to a source package which is as
>> platform-independent as you can make it. If you don't want to distribute
>> your source you can try for Java but then Java can be disassembled easily.
>
> No the LSB is a good step in this direction and i hope that people see
> that we need binary compatibility across the major non geek Desktop
> distributions.

The only people who would 'need' this are the people who want to
distribute binaries without source for some reason. And even these
actually don't: What they need is not an identical operating
environment everywhere, but a runtime environment which is compatible
with the environment used to develop some software. This can easily be
achieved by picking some set of 'supported' platforms and documenting
the compatibility requirements, so that people intending to use the
software on a non-supported platform can create such a compatible
environment if they so desire.

On 29 Feb., 12:54, Rainer Weikusat wrote:

> with the environment used to develop some software. This can easily be
> achieved by picking some set of 'supported' platforms and documenting
> the compatibility requirements, so that people intending to use the
> software on a non-supported platform can create such a compatible
> environment if they so desire.

Well this is all what LSB is about.

I have some customers who are doing what you propose on MacOSX.
They purchased parallels emulator and run the windows version
on there Macs. But virtualisation is extremely heavyweigth and all
this
appliances (the new hype in the IT) is not a solution for a desktop
application. It's contradictionary. You want them to integrate not
isolate.

I really liked what i learned about LSB in the last days - the
documentation
is pretty easy to read. But i guess some geeks will ruin the effords
again.

Unfortunately the http://www.linux-foundation.org/ is also not good in
evangelism
for there linux standard base. They should really setup a list with
all conforming
apps, help the ISV's to market the applications and ideas and reduce
there ****ing
fees to get a formal certification to maybe 10% of what they charge
now.
Certification for "Designed for Windows XXX" is exactly doing this
(its about US$ 129)
the last time i had looked at it.

This guys still have the attitude of all the UNIX consortiums that i
have seen in the
last millenium. They never learn. And from there application database
i see that they
have less certifcations then SCO is having active Unix users.

Thats why one organization is following the next and the next and the
next.
Welcome to the Unix world. I'm shaking my head about this since i
first
switched on a DEC Workstation in 1988.

llothar writes:
> On 29 Feb., 12:54, Rainer Weikusat wrote:
>> with the environment used to develop some software. This can easily be
>> achieved by picking some set of 'supported' platforms and documenting
>> the compatibility requirements, so that people intending to use the
>> software on a non-supported platform can create such a compatible
>> environment if they so desire.
>
> Well this is all what LSB is about.

No. The LSB would be one of the many possibly supported platforms.

> I have some customers who are doing what you propose on MacOSX.
> They purchased parallels emulator and run the windows version
> on there Macs.

That was not what I proposed. If I want to run a certain software on
some OS with some Linux-kernel, I can install any version of any (open
source) library the software may need on this system and if this isn't
enough, I could even change it as required, if I think that it would
be worth the effort. Eg my employer runs binary-only Checkpoint
software on CentOS with a small kernel modification to make it work.

On 29 Feb., 17:10, Rainer Weikusat wrote:
> llothar writes:
> > On 29 Feb., 12:54, Rainer Weikusat wrote:
> >> with the environment used to develop some software. This can easily be
> >> achieved by picking some set of 'supported' platforms and documenting
> >> the compatibility requirements, so that people intending to use the
> >> software on a non-supported platform can create such a compatible
> >> environment if they so desire.
>
> > Well this is all what LSB is about.
>
> No. The LSB would be one of the many possibly supported platforms.
>
> > I have some customers who are doing what you propose on MacOSX.
> > They purchased parallels emulator and run the windows version
> > on there Macs.
>
> That was not what I proposed. If I want to run a certain software on
> some OS with some Linux-kernel, I can install any version of any (open
> source) library the software may need on this system and if this isn't
> enough, I could even change it as required, if I think that it would

No i'm talking about a commercial Desktop Application in the 50-100 US
$
range like most desktop software is now. Nobody want ever change
anything to get it going.

> be worth the effort. Eg my employer runs binary-only Checkpoint
> software on CentOS with a small kernel modification to make it work.

I remember this from ultra expensive CAD software etc.
I don't think that anybody needs a standard for this kind of software
because
the customer normally choose the certified OS for there software and
not the other way round. This is Workstation world and just a very
small
part of Desktop world.