[suggest] Re: suggest Digest, Vol 60, Issue 13

[Nico Kadel-Garcia]

Date: Mon, 14 Jun 2010 11:45:13 +0200
From: "Yury V. Zaytsev" <yury at shurup.com>
Subject: Re: QRe: [suggest] please update libdvbpsi
To: arnebjarne72 at hotmail.com
Cc: suggest at lists.rpmforge.net
Message-ID: <1276508713.7686.35.camel at mypride>
Content-Type: text/plain
Hi!

I can compile VLC without the Qt4 GUI, making cvlc work.

The reason is very simple: the developers migrate to newer distributions
that ship newer Qt that comes with new features and bug fixes. The
interface resource files format is not backwards compatible, so it's a
constant pain to make sure that things still work on older
distributions.
No developers use RHEL 5 anymore, so they just don't care whether it
still works there or not.

But RHEL 5 is still the latest RedHat production release. It's gotten
quite old, I admit, and am eagerly awaiting RHEL 6. But we've seen
similar nuttiness with Subversion on both RHEL 5 and especially on
RHEL 4. If you want people in business/production environments to use
a tool, then it helps if it will compile there.

In fact, the Subversion .spec file has some useful configuration
differences for RHEL 4 and RHEL 5. Perhaps the VLC .spec could do
something differently for RHEL 5?

I started changing and backporting the failing QT4 code, but stopped
again. I guess the code was changed for a reason and I have no clue
what impact changing the code from Qt 4.4.0 back to Qt 4.2.1 code
(from vlc 0.9.8).

This is something I did for SMPlayer when I was still using CentOS for
multimedia and wanted a decent recent mplayer front-end. It's a heroic
effort and you need some expertise.
If you want to go this route I'd rather had a look at 0.9.9a instead.
I think the most practical solution would be in fact to come up with
static builds of VLC against latest Qt.

Ouch. That's generally something to avoid. It's done for a few small
components of Subversion, like SQLite, to avoid that kind of system
library issue.

Then, we would be able to switch all the packages that require newer Qt
to buildrequire this package and statically link against its libraries,
which will be kind of Qt backporting framework.

That's a big indeavor, providing all the system components in newer
versions. I've seen people try that stunt, but it usually breaks down
pretty fast because they wind up failing ot update speficic
components.

One thinig people do is build a separate, slightly different named
package. For example, "gcc-4.x" is released in parallel with gcc-3.x
with the name "gcc4-4.x".

However, I don't have time and energy do mess with it. I don't need it
anymore for myself and I'm not gonna get paid for it.
If you want to have a go at it I wish you best of luck... :-)

Agreed, it's a lot of work.

[Yury V. Zaytsev]

Post by Nico Kadel-Garcia
But RHEL 5 is still the latest RedHat production release. It's gotten
quite old, I admit, and am eagerly awaiting RHEL 6. But we've seen
similar nuttiness with Subversion on both RHEL 5 and especially on
RHEL 4. If you want people in business/production environments to use
a tool, then it helps if it will compile there.

You are telling this to me? :-)
You'd rather explain this to VLC developers.

Post by Nico Kadel-Garcia
In fact, the Subversion .spec file has some useful configuration
differences for RHEL 4 and RHEL 5. Perhaps the VLC .spec could do
something differently for RHEL 5?

No. Unless you want a command-line interface only. Which is probably
worse than 0.9.9a.

Post by Nico Kadel-Garcia
One thinig people do is build a separate, slightly different named
package. For example, "gcc-4.x" is released in parallel with gcc-3.x
with the name "gcc4-4.x".

It is impossible to make a parallel-installable version of qt4. At least
not without help from Redhat.

[Pavel Kankovsky]

Post by Yury V. Zaytsev
It is impossible to make a parallel-installable version of qt4. At least
not without help from Redhat.

Really? qt4 packages in RHEL5 are built with --prefix=/usr/lib/qt4
and almost everything is put there. What makes it impossible to build
another instance of Qt4 with different prefix and perhaps a small
discriminator in sonames?

[Yury V. Zaytsev]

Hi!

Post by Pavel Kankovsky
Really? qt4 packages in RHEL5 are built with --prefix=/usr/lib/qt4
and almost everything is put there. What makes it impossible to build
another instance of Qt4 with different prefix and perhaps a small
discriminator in sonames?

Apart from these, there are

1) pkgconfig files installed in /usr/lib/pkgconfig
2) symlinks to the libraries

How am I supposed to deal with this?

Mendeley Desktop, for instance, installs its own weird version of qt
in /opt and then plays tricks with LD_LIBRARY_PATHs.

This all looks very very dirty to me and the static solution is way much
cleaner, it's just that one needs time to implement it properly.

[Bjarne Saltbaek]

Hi *.

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
It is impossible to make a parallel-installable version of qt4. At least
not without help from Redhat.

Really? qt4 packages in RHEL5 are built with --prefix=/usr/lib/qt4
and almost everything is put there. What makes it impossible to build
another instance of Qt4 with different prefix and perhaps a small
discriminator in sonames?

I have looked at http://svn.rpmforge.net/svn/trunk/rpms/vlc/vlc-test.spec

I see:

--- cut ---
### Workaround to make -lX11 work on 64bit
export LDFLAGS="-L/usr/X11R6/%{_lib}"
export QTDIR="$(/usr/bin/pkg-config --variable=prefix QtGui)"
export PATH="$QTDIR/bin:$PATH"
export QTINC="$QTDIR/include"
export QTLIB="$QTDIR/lib"

--- cut ---

So, if we build a Qt under ie. /usr/lib/vlc/qt4 and change the above QTDIR
(from /usr/lib/qt4) - will this work?


Regards,
Bjarne

[Yury V. Zaytsev]

Hi!

Post by Bjarne Saltbaek
--- cut ---
### Workaround to make -lX11 work on 64bit
export LDFLAGS="-L/usr/X11R6/%{_lib}"
export QTDIR="$(/usr/bin/pkg-config --variable=prefix QtGui)"
export PATH="$QTDIR/bin:$PATH"
export QTINC="$QTDIR/include"
export QTLIB="$QTDIR/lib"
--- cut ---
So, if we build a Qt under ie. /usr/lib/vlc/qt4 and change the above QTDIR
(from /usr/lib/qt4) - will this work?

The build itself has a potential to work, but what will happen is that
vlc will be linked dynamically against a set of libraries that are not
exposed to ld, so the application will fail to run (unless you set the
RPATH to /usr/lib/vlc/qt4, which is a whole another story).

If you do a static build of qt (I don't remember the details anymore,
but all it takes, I guess, is to add the -static switch to the *.pro
file), it will get linked directly in the executables and will not
require to have qt installed in order to run.

The whole debate about static vs. dynamic linking can be summarized this
way, I guess: "if we do dynamic linking, we have to make a separate
proper parallel-installable package of qt for everything, if we do
static linking, probably we don't".

[Yury V. Zaytsev]

Hi!

Post by Bjarne Saltbaek
--- cut ---
### Workaround to make -lX11 work on 64bit
export LDFLAGS="-L/usr/X11R6/%{_lib}"
export QTDIR="$(/usr/bin/pkg-config --variable=prefix QtGui)"
export PATH="$QTDIR/bin:$PATH"
export QTINC="$QTDIR/include"
export QTLIB="$QTDIR/lib"
--- cut ---
So, if we build a Qt under ie. /usr/lib/vlc/qt4 and change the above QTDIR
(from /usr/lib/qt4) - will this work?

The build itself has a potential to work, but what will happen is that
vlc will be linked dynamically against a set of libraries that are not
exposed to ld, so the application will fail to run (unless you set the
RPATH to /usr/lib/vlc/qt4, which is a whole another story).

If you do a static build of qt (I don't remember the details anymore,
but all it takes, I guess, is to add the -static switch to the *.pro
file), it will get linked directly in the executables and will not
require to have qt installed in order to run.

The whole debate about static vs. dynamic linking can be summarized this
way, I guess: "if we do dynamic linking, we have to make a separate
proper parallel-installable package of qt for everything, if we do
static linking, probably we don't".

[Yury V. Zaytsev]

Hi!

Post by Bjarne Saltbaek
--- cut ---
### Workaround to make -lX11 work on 64bit
export LDFLAGS="-L/usr/X11R6/%{_lib}"
export QTDIR="$(/usr/bin/pkg-config --variable=prefix QtGui)"
export PATH="$QTDIR/bin:$PATH"
export QTINC="$QTDIR/include"
export QTLIB="$QTDIR/lib"
--- cut ---
So, if we build a Qt under ie. /usr/lib/vlc/qt4 and change the above QTDIR
(from /usr/lib/qt4) - will this work?

The build itself has a potential to work, but what will happen is that
vlc will be linked dynamically against a set of libraries that are not
exposed to ld, so the application will fail to run (unless you set the
RPATH to /usr/lib/vlc/qt4, which is a whole another story).

If you do a static build of qt (I don't remember the details anymore,
but all it takes, I guess, is to add the -static switch to the *.pro
file), it will get linked directly in the executables and will not
require to have qt installed in order to run.

The whole debate about static vs. dynamic linking can be summarized this
way, I guess: "if we do dynamic linking, we have to make a separate
proper parallel-installable package of qt for everything, if we do
static linking, probably we don't".

[Yury V. Zaytsev]

Hi!

Post by Bjarne Saltbaek
--- cut ---
### Workaround to make -lX11 work on 64bit
export LDFLAGS="-L/usr/X11R6/%{_lib}"
export QTDIR="$(/usr/bin/pkg-config --variable=prefix QtGui)"
export PATH="$QTDIR/bin:$PATH"
export QTINC="$QTDIR/include"
export QTLIB="$QTDIR/lib"
--- cut ---
So, if we build a Qt under ie. /usr/lib/vlc/qt4 and change the above QTDIR
(from /usr/lib/qt4) - will this work?

The build itself has a potential to work, but what will happen is that
vlc will be linked dynamically against a set of libraries that are not
exposed to ld, so the application will fail to run (unless you set the
RPATH to /usr/lib/vlc/qt4, which is a whole another story).

If you do a static build of qt (I don't remember the details anymore,
but all it takes, I guess, is to add the -static switch to the *.pro
file), it will get linked directly in the executables and will not
require to have qt installed in order to run.

The whole debate about static vs. dynamic linking can be summarized this
way, I guess: "if we do dynamic linking, we have to make a separate
proper parallel-installable package of qt for everything, if we do
static linking, probably we don't".

[Yury V. Zaytsev]

Hi!

Post by Bjarne Saltbaek
--- cut ---
### Workaround to make -lX11 work on 64bit
export LDFLAGS="-L/usr/X11R6/%{_lib}"
export QTDIR="$(/usr/bin/pkg-config --variable=prefix QtGui)"
export PATH="$QTDIR/bin:$PATH"
export QTINC="$QTDIR/include"
export QTLIB="$QTDIR/lib"
--- cut ---
So, if we build a Qt under ie. /usr/lib/vlc/qt4 and change the above QTDIR
(from /usr/lib/qt4) - will this work?

The build itself has a potential to work, but what will happen is that
vlc will be linked dynamically against a set of libraries that are not
exposed to ld, so the application will fail to run (unless you set the
RPATH to /usr/lib/vlc/qt4, which is a whole another story).

If you do a static build of qt (I don't remember the details anymore,
but all it takes, I guess, is to add the -static switch to the *.pro
file), it will get linked directly in the executables and will not
require to have qt installed in order to run.

The whole debate about static vs. dynamic linking can be summarized this
way, I guess: "if we do dynamic linking, we have to make a separate
proper parallel-installable package of qt for everything, if we do
static linking, probably we don't".

[Yury V. Zaytsev]

Hi!

Post by Pavel Kankovsky
Really? qt4 packages in RHEL5 are built with --prefix=/usr/lib/qt4
and almost everything is put there. What makes it impossible to build
another instance of Qt4 with different prefix and perhaps a small
discriminator in sonames?

Apart from these, there are

1) pkgconfig files installed in /usr/lib/pkgconfig
2) symlinks to the libraries

How am I supposed to deal with this?

Mendeley Desktop, for instance, installs its own weird version of qt
in /opt and then plays tricks with LD_LIBRARY_PATHs.

This all looks very very dirty to me and the static solution is way much
cleaner, it's just that one needs time to implement it properly.

[Bjarne Saltbaek]

Hi *.

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
It is impossible to make a parallel-installable version of qt4. At least
not without help from Redhat.

Really? qt4 packages in RHEL5 are built with --prefix=/usr/lib/qt4
and almost everything is put there. What makes it impossible to build
another instance of Qt4 with different prefix and perhaps a small
discriminator in sonames?

I have looked at http://svn.rpmforge.net/svn/trunk/rpms/vlc/vlc-test.spec

I see:

--- cut ---
### Workaround to make -lX11 work on 64bit
export LDFLAGS="-L/usr/X11R6/%{_lib}"
export QTDIR="$(/usr/bin/pkg-config --variable=prefix QtGui)"
export PATH="$QTDIR/bin:$PATH"
export QTINC="$QTDIR/include"
export QTLIB="$QTDIR/lib"

--- cut ---

So, if we build a Qt under ie. /usr/lib/vlc/qt4 and change the above QTDIR
(from /usr/lib/qt4) - will this work?


Regards,
Bjarne

[Yury V. Zaytsev]

Hi!

Post by Pavel Kankovsky
Really? qt4 packages in RHEL5 are built with --prefix=/usr/lib/qt4
and almost everything is put there. What makes it impossible to build
another instance of Qt4 with different prefix and perhaps a small
discriminator in sonames?

Apart from these, there are

1) pkgconfig files installed in /usr/lib/pkgconfig
2) symlinks to the libraries

How am I supposed to deal with this?

Mendeley Desktop, for instance, installs its own weird version of qt
in /opt and then plays tricks with LD_LIBRARY_PATHs.

This all looks very very dirty to me and the static solution is way much
cleaner, it's just that one needs time to implement it properly.

[Bjarne Saltbaek]

Hi *.

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
It is impossible to make a parallel-installable version of qt4. At least
not without help from Redhat.

Really? qt4 packages in RHEL5 are built with --prefix=/usr/lib/qt4
and almost everything is put there. What makes it impossible to build
another instance of Qt4 with different prefix and perhaps a small
discriminator in sonames?

I have looked at http://svn.rpmforge.net/svn/trunk/rpms/vlc/vlc-test.spec

I see:

--- cut ---
### Workaround to make -lX11 work on 64bit
export LDFLAGS="-L/usr/X11R6/%{_lib}"
export QTDIR="$(/usr/bin/pkg-config --variable=prefix QtGui)"
export PATH="$QTDIR/bin:$PATH"
export QTINC="$QTDIR/include"
export QTLIB="$QTDIR/lib"

--- cut ---

So, if we build a Qt under ie. /usr/lib/vlc/qt4 and change the above QTDIR
(from /usr/lib/qt4) - will this work?


Regards,
Bjarne

[Yury V. Zaytsev]

Hi!

Post by Pavel Kankovsky
Really? qt4 packages in RHEL5 are built with --prefix=/usr/lib/qt4
and almost everything is put there. What makes it impossible to build
another instance of Qt4 with different prefix and perhaps a small
discriminator in sonames?

Apart from these, there are

1) pkgconfig files installed in /usr/lib/pkgconfig
2) symlinks to the libraries

How am I supposed to deal with this?

Mendeley Desktop, for instance, installs its own weird version of qt
in /opt and then plays tricks with LD_LIBRARY_PATHs.

This all looks very very dirty to me and the static solution is way much
cleaner, it's just that one needs time to implement it properly.

[Bjarne Saltbaek]

Hi *.

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
It is impossible to make a parallel-installable version of qt4. At least
not without help from Redhat.

Really? qt4 packages in RHEL5 are built with --prefix=/usr/lib/qt4
and almost everything is put there. What makes it impossible to build
another instance of Qt4 with different prefix and perhaps a small
discriminator in sonames?

I have looked at http://svn.rpmforge.net/svn/trunk/rpms/vlc/vlc-test.spec

I see:

--- cut ---
### Workaround to make -lX11 work on 64bit
export LDFLAGS="-L/usr/X11R6/%{_lib}"
export QTDIR="$(/usr/bin/pkg-config --variable=prefix QtGui)"
export PATH="$QTDIR/bin:$PATH"
export QTINC="$QTDIR/include"
export QTLIB="$QTDIR/lib"

--- cut ---

So, if we build a Qt under ie. /usr/lib/vlc/qt4 and change the above QTDIR
(from /usr/lib/qt4) - will this work?


Regards,
Bjarne

[Yury V. Zaytsev]

Hi!

Post by Pavel Kankovsky
Really? qt4 packages in RHEL5 are built with --prefix=/usr/lib/qt4
and almost everything is put there. What makes it impossible to build
another instance of Qt4 with different prefix and perhaps a small
discriminator in sonames?

Apart from these, there are

1) pkgconfig files installed in /usr/lib/pkgconfig
2) symlinks to the libraries

How am I supposed to deal with this?

Mendeley Desktop, for instance, installs its own weird version of qt
in /opt and then plays tricks with LD_LIBRARY_PATHs.

This all looks very very dirty to me and the static solution is way much
cleaner, it's just that one needs time to implement it properly.

[Bjarne Saltbaek]

Hi *.

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
It is impossible to make a parallel-installable version of qt4. At least
not without help from Redhat.

Really? qt4 packages in RHEL5 are built with --prefix=/usr/lib/qt4
and almost everything is put there. What makes it impossible to build
another instance of Qt4 with different prefix and perhaps a small
discriminator in sonames?

I have looked at http://svn.rpmforge.net/svn/trunk/rpms/vlc/vlc-test.spec

I see:

--- cut ---
### Workaround to make -lX11 work on 64bit
export LDFLAGS="-L/usr/X11R6/%{_lib}"
export QTDIR="$(/usr/bin/pkg-config --variable=prefix QtGui)"
export PATH="$QTDIR/bin:$PATH"
export QTINC="$QTDIR/include"
export QTLIB="$QTDIR/lib"

--- cut ---

So, if we build a Qt under ie. /usr/lib/vlc/qt4 and change the above QTDIR
(from /usr/lib/qt4) - will this work?


Regards,
Bjarne

[Pavel Kankovsky]

Post by Yury V. Zaytsev
1) pkgconfig files installed in /usr/lib/pkgconfig

Put them elsewhere and use PKG_CONFIG_PATH when you need them.

Post by Yury V. Zaytsev
2) symlinks to the libraries

What symlinks? Do you mean things like libQtCore.so.4 (ie. the soname)
pointing at libQtCore.so.4.2.1 (ie. the real filename)? If the new version
ABI is not upward compatible with the old version bundled in the distro
but the new version builds with the same sonames by default then the right
solution is to change the soname of the new version.

Post by Yury V. Zaytsev
This all looks very very dirty to me and the static solution is way much
cleaner, it's just that one needs time to implement it properly.

It does not scale up very well, IMHO.

[Yury V. Zaytsev]

Hi!

Post by Pavel Kankovsky
Put them elsewhere and use PKG_CONFIG_PATH when you need them.

Right, I didn't think about it, might be an option...

Post by Pavel Kankovsky
What symlinks? Do you mean things like libQtCore.so.4 (ie. the soname)
pointing at libQtCore.so.4.2.1 (ie. the real filename)? If the new version
ABI is not upward compatible with the old version bundled in the distro
but the new version builds with the same sonames by default then the right
solution is to change the soname of the new version.

Yep. No, usually the ABI is not upward compatible.

I am not familiar with dynamically linked libraries management on Linux.
What do you mean by "change the soname"? Shall I just rename the so to
libQtCore.so.4.5.4 and remove the synlinks?

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
This all looks very very dirty to me and the static solution is way much
cleaner, it's just that one needs time to implement it properly.

It does not scale up very well, IMHO.

Oh really? What would be the potential problems that I'd face?

Actually I have never built static versions of Qt on Linux, but I did so
on Windows and the size of the resulting executables was in the range of
few Mbs which will be definitively a hardly noticeable increase.

All it would take is to add a static blob in the SPEC in %build to build
Qt just as I did for curl / rtorrent and what was later accepted as a
more or less universal solution for backporting packages that require
few libraries that are impossible to update globally...

[Yury V. Zaytsev]

Hi!

Post by Pavel Kankovsky
Put them elsewhere and use PKG_CONFIG_PATH when you need them.

Right, I didn't think about it, might be an option...

Post by Pavel Kankovsky
What symlinks? Do you mean things like libQtCore.so.4 (ie. the soname)
pointing at libQtCore.so.4.2.1 (ie. the real filename)? If the new version
ABI is not upward compatible with the old version bundled in the distro
but the new version builds with the same sonames by default then the right
solution is to change the soname of the new version.

Yep. No, usually the ABI is not upward compatible.

I am not familiar with dynamically linked libraries management on Linux.
What do you mean by "change the soname"? Shall I just rename the so to
libQtCore.so.4.5.4 and remove the synlinks?

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
This all looks very very dirty to me and the static solution is way much
cleaner, it's just that one needs time to implement it properly.

It does not scale up very well, IMHO.

Oh really? What would be the potential problems that I'd face?

Actually I have never built static versions of Qt on Linux, but I did so
on Windows and the size of the resulting executables was in the range of
few Mbs which will be definitively a hardly noticeable increase.

All it would take is to add a static blob in the SPEC in %build to build
Qt just as I did for curl / rtorrent and what was later accepted as a
more or less universal solution for backporting packages that require
few libraries that are impossible to update globally...

[Yury V. Zaytsev]

Hi!

Post by Pavel Kankovsky
Put them elsewhere and use PKG_CONFIG_PATH when you need them.

Right, I didn't think about it, might be an option...

Post by Pavel Kankovsky
What symlinks? Do you mean things like libQtCore.so.4 (ie. the soname)
pointing at libQtCore.so.4.2.1 (ie. the real filename)? If the new version
ABI is not upward compatible with the old version bundled in the distro
but the new version builds with the same sonames by default then the right
solution is to change the soname of the new version.

Yep. No, usually the ABI is not upward compatible.

I am not familiar with dynamically linked libraries management on Linux.
What do you mean by "change the soname"? Shall I just rename the so to
libQtCore.so.4.5.4 and remove the synlinks?

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
This all looks very very dirty to me and the static solution is way much
cleaner, it's just that one needs time to implement it properly.

It does not scale up very well, IMHO.

Oh really? What would be the potential problems that I'd face?

Actually I have never built static versions of Qt on Linux, but I did so
on Windows and the size of the resulting executables was in the range of
few Mbs which will be definitively a hardly noticeable increase.

All it would take is to add a static blob in the SPEC in %build to build
Qt just as I did for curl / rtorrent and what was later accepted as a
more or less universal solution for backporting packages that require
few libraries that are impossible to update globally...

[Yury V. Zaytsev]

Hi!

Post by Pavel Kankovsky
Put them elsewhere and use PKG_CONFIG_PATH when you need them.

Right, I didn't think about it, might be an option...

Post by Pavel Kankovsky
What symlinks? Do you mean things like libQtCore.so.4 (ie. the soname)
pointing at libQtCore.so.4.2.1 (ie. the real filename)? If the new version
ABI is not upward compatible with the old version bundled in the distro
but the new version builds with the same sonames by default then the right
solution is to change the soname of the new version.

Yep. No, usually the ABI is not upward compatible.

I am not familiar with dynamically linked libraries management on Linux.
What do you mean by "change the soname"? Shall I just rename the so to
libQtCore.so.4.5.4 and remove the synlinks?

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
This all looks very very dirty to me and the static solution is way much
cleaner, it's just that one needs time to implement it properly.

It does not scale up very well, IMHO.

Oh really? What would be the potential problems that I'd face?

Actually I have never built static versions of Qt on Linux, but I did so
on Windows and the size of the resulting executables was in the range of
few Mbs which will be definitively a hardly noticeable increase.

All it would take is to add a static blob in the SPEC in %build to build
Qt just as I did for curl / rtorrent and what was later accepted as a
more or less universal solution for backporting packages that require
few libraries that are impossible to update globally...

[Yury V. Zaytsev]

Hi!

Post by Pavel Kankovsky
Put them elsewhere and use PKG_CONFIG_PATH when you need them.

Right, I didn't think about it, might be an option...

Post by Pavel Kankovsky
What symlinks? Do you mean things like libQtCore.so.4 (ie. the soname)
pointing at libQtCore.so.4.2.1 (ie. the real filename)? If the new version
ABI is not upward compatible with the old version bundled in the distro
but the new version builds with the same sonames by default then the right
solution is to change the soname of the new version.

Yep. No, usually the ABI is not upward compatible.

I am not familiar with dynamically linked libraries management on Linux.
What do you mean by "change the soname"? Shall I just rename the so to
libQtCore.so.4.5.4 and remove the synlinks?

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
This all looks very very dirty to me and the static solution is way much
cleaner, it's just that one needs time to implement it properly.

It does not scale up very well, IMHO.

Oh really? What would be the potential problems that I'd face?

Actually I have never built static versions of Qt on Linux, but I did so
on Windows and the size of the resulting executables was in the range of
few Mbs which will be definitively a hardly noticeable increase.

All it would take is to add a static blob in the SPEC in %build to build
Qt just as I did for curl / rtorrent and what was later accepted as a
more or less universal solution for backporting packages that require
few libraries that are impossible to update globally...

[Pavel Kankovsky]

Post by Yury V. Zaytsev
Yep. No, usually the ABI is not upward compatible.

Hmm... it is probably compatible (or is supposed to be) in this case
at least up to 4.4.3.
<http://qt.nokia.com/developer/changes/changes-4.4.3> says:
"Applications compiled for 4.0, 4.1, 4.2, and 4.3 will continue to run
with 4.4."

Post by Yury V. Zaytsev
I am not familiar with dynamically linked libraries management on Linux.
What do you mean by "change the soname"? Shall I just rename the so to
libQtCore.so.4.5.4 and remove the synlinks?

ELF dynamic libraries include their "true names" called "soname" (I guess
it stands for "shared object name") in their .dynamic section.

When you link a program with a dynamic library using "-llibrary" the
linker finds "library.so", reads its soname, and adds dependency to the
soname (rather than to "library.so") to the resulting executable file.

A dynamic library having a certain soname is supposed to be binary
compatible with any program depending on the same soname in the sense that
either the program works correctly or it fails to start due to missing
symbols.

A common convention is to use "library.so.1" (where 1 is the generation of
ABI) as a soname and "library.so.1.2.3" (where 1.2.3 is the version of the
library) as a filename, and to let ldconfig symlink soname to filename.

Post by Yury V. Zaytsev

Post by Pavel Kankovsky
It does not scale up very well, IMHO.

Oh really? What would be the potential problems that I'd face?

Qt is a big library. Much bigger than SQLite or libcurl. You'd get
1. bloated source packages, 2. slow rebuild times, and 3. bloated binary
packages if you bundled a private copy of Qt with every package needing
it.

Issues 1 and 2 might be eliminated if there was a standalone
static-library-only devel package of Qt (and perhaps a small runtime
package if any data files are needed).

[Yury V. Zaytsev]

Hi!

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
Yep. No, usually the ABI is not upward compatible.

Hmm... it is probably compatible (or is supposed to be) in this case
at least up to 4.4.3.

Well, that's true, but we would really want to have at least Qt 4.5 if
not 4.6 for our purposes. Many packages nowadays require at least Qt 4.5
and if we limit ourselves to 4.4 to be backwards compatible, it means
that most of these porting efforts do not make much sense.

Post by Pavel Kankovsky
A common convention is to use "library.so.1" (where 1 is the generation of
ABI) as a soname and "library.so.1.2.3" (where 1.2.3 is the version of the
library) as a filename, and to let ldconfig symlink soname to filename.

Thanks you very much for an exhaustive explanation. Now I more or less
understand what you are talking about. Still, I guess I need to Google
quite a bit to see how to implement this in practice...

... but still, I am not convinced that this is the way to go.

Post by Pavel Kankovsky
Qt is a big library. Much bigger than SQLite or libcurl. You'd get
1. bloated source packages, 2. slow rebuild times, and 3. bloated binary
packages if you bundled a private copy of Qt with every package needing
it.

I know this. However, as I stated, I did static builds on Windows with
mingw and the resulting binaries using basic Qt stuff were in the range
of 1-2 Mbs. Do extra 1-2 Mbs really matter when you are talking about a
monstrous 25 Mb worth of libs of vlc?

Post by Pavel Kankovsky
Issues 1 and 2 might be eliminated if there was a standalone
static-library-only devel package of Qt (and perhaps a small runtime
package if any data files are needed).

Yes, this is what I was suggesting to do in view of these two problems.
And I might even actually get some time one day to get to it...

[Yury V. Zaytsev]

Hi!

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
Yep. No, usually the ABI is not upward compatible.

Hmm... it is probably compatible (or is supposed to be) in this case
at least up to 4.4.3.

Well, that's true, but we would really want to have at least Qt 4.5 if
not 4.6 for our purposes. Many packages nowadays require at least Qt 4.5
and if we limit ourselves to 4.4 to be backwards compatible, it means
that most of these porting efforts do not make much sense.

Post by Pavel Kankovsky
A common convention is to use "library.so.1" (where 1 is the generation of
ABI) as a soname and "library.so.1.2.3" (where 1.2.3 is the version of the
library) as a filename, and to let ldconfig symlink soname to filename.

Thanks you very much for an exhaustive explanation. Now I more or less
understand what you are talking about. Still, I guess I need to Google
quite a bit to see how to implement this in practice...

... but still, I am not convinced that this is the way to go.

Post by Pavel Kankovsky
Qt is a big library. Much bigger than SQLite or libcurl. You'd get
1. bloated source packages, 2. slow rebuild times, and 3. bloated binary
packages if you bundled a private copy of Qt with every package needing
it.

I know this. However, as I stated, I did static builds on Windows with
mingw and the resulting binaries using basic Qt stuff were in the range
of 1-2 Mbs. Do extra 1-2 Mbs really matter when you are talking about a
monstrous 25 Mb worth of libs of vlc?

Post by Pavel Kankovsky
Issues 1 and 2 might be eliminated if there was a standalone
static-library-only devel package of Qt (and perhaps a small runtime
package if any data files are needed).

Yes, this is what I was suggesting to do in view of these two problems.
And I might even actually get some time one day to get to it...

[Yury V. Zaytsev]

Hi!

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
Yep. No, usually the ABI is not upward compatible.

Hmm... it is probably compatible (or is supposed to be) in this case
at least up to 4.4.3.

Well, that's true, but we would really want to have at least Qt 4.5 if
not 4.6 for our purposes. Many packages nowadays require at least Qt 4.5
and if we limit ourselves to 4.4 to be backwards compatible, it means
that most of these porting efforts do not make much sense.

Post by Pavel Kankovsky
A common convention is to use "library.so.1" (where 1 is the generation of
ABI) as a soname and "library.so.1.2.3" (where 1.2.3 is the version of the
library) as a filename, and to let ldconfig symlink soname to filename.

Thanks you very much for an exhaustive explanation. Now I more or less
understand what you are talking about. Still, I guess I need to Google
quite a bit to see how to implement this in practice...

... but still, I am not convinced that this is the way to go.

Post by Pavel Kankovsky
Qt is a big library. Much bigger than SQLite or libcurl. You'd get
1. bloated source packages, 2. slow rebuild times, and 3. bloated binary
packages if you bundled a private copy of Qt with every package needing
it.

I know this. However, as I stated, I did static builds on Windows with
mingw and the resulting binaries using basic Qt stuff were in the range
of 1-2 Mbs. Do extra 1-2 Mbs really matter when you are talking about a
monstrous 25 Mb worth of libs of vlc?

Post by Pavel Kankovsky
Issues 1 and 2 might be eliminated if there was a standalone
static-library-only devel package of Qt (and perhaps a small runtime
package if any data files are needed).

Yes, this is what I was suggesting to do in view of these two problems.
And I might even actually get some time one day to get to it...

[Yury V. Zaytsev]

Hi!

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
Yep. No, usually the ABI is not upward compatible.

Hmm... it is probably compatible (or is supposed to be) in this case
at least up to 4.4.3.

Well, that's true, but we would really want to have at least Qt 4.5 if
not 4.6 for our purposes. Many packages nowadays require at least Qt 4.5
and if we limit ourselves to 4.4 to be backwards compatible, it means
that most of these porting efforts do not make much sense.

Post by Pavel Kankovsky
A common convention is to use "library.so.1" (where 1 is the generation of
ABI) as a soname and "library.so.1.2.3" (where 1.2.3 is the version of the
library) as a filename, and to let ldconfig symlink soname to filename.

Thanks you very much for an exhaustive explanation. Now I more or less
understand what you are talking about. Still, I guess I need to Google
quite a bit to see how to implement this in practice...

... but still, I am not convinced that this is the way to go.

Post by Pavel Kankovsky
Qt is a big library. Much bigger than SQLite or libcurl. You'd get
1. bloated source packages, 2. slow rebuild times, and 3. bloated binary
packages if you bundled a private copy of Qt with every package needing
it.

I know this. However, as I stated, I did static builds on Windows with
mingw and the resulting binaries using basic Qt stuff were in the range
of 1-2 Mbs. Do extra 1-2 Mbs really matter when you are talking about a
monstrous 25 Mb worth of libs of vlc?

Post by Pavel Kankovsky
Issues 1 and 2 might be eliminated if there was a standalone
static-library-only devel package of Qt (and perhaps a small runtime
package if any data files are needed).

Yes, this is what I was suggesting to do in view of these two problems.
And I might even actually get some time one day to get to it...

[Yury V. Zaytsev]

Hi!

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
Yep. No, usually the ABI is not upward compatible.

Hmm... it is probably compatible (or is supposed to be) in this case
at least up to 4.4.3.

Well, that's true, but we would really want to have at least Qt 4.5 if
not 4.6 for our purposes. Many packages nowadays require at least Qt 4.5
and if we limit ourselves to 4.4 to be backwards compatible, it means
that most of these porting efforts do not make much sense.

Post by Pavel Kankovsky
A common convention is to use "library.so.1" (where 1 is the generation of
ABI) as a soname and "library.so.1.2.3" (where 1.2.3 is the version of the
library) as a filename, and to let ldconfig symlink soname to filename.

Thanks you very much for an exhaustive explanation. Now I more or less
understand what you are talking about. Still, I guess I need to Google
quite a bit to see how to implement this in practice...

... but still, I am not convinced that this is the way to go.

Post by Pavel Kankovsky
Qt is a big library. Much bigger than SQLite or libcurl. You'd get
1. bloated source packages, 2. slow rebuild times, and 3. bloated binary
packages if you bundled a private copy of Qt with every package needing
it.

I know this. However, as I stated, I did static builds on Windows with
mingw and the resulting binaries using basic Qt stuff were in the range
of 1-2 Mbs. Do extra 1-2 Mbs really matter when you are talking about a
monstrous 25 Mb worth of libs of vlc?

Post by Pavel Kankovsky
Issues 1 and 2 might be eliminated if there was a standalone
static-library-only devel package of Qt (and perhaps a small runtime
package if any data files are needed).

Yes, this is what I was suggesting to do in view of these two problems.
And I might even actually get some time one day to get to it...

[Nico Kadel-Garcia]

Date: Mon, 14 Jun 2010 11:45:13 +0200
From: "Yury V. Zaytsev" <yury at shurup.com>
Subject: Re: QRe: [suggest] please update libdvbpsi
To: arnebjarne72 at hotmail.com
Cc: suggest at lists.rpmforge.net
Message-ID: <1276508713.7686.35.camel at mypride>
Content-Type: text/plain
Hi!

I can compile VLC without the Qt4 GUI, making cvlc work.

The reason is very simple: the developers migrate to newer distributions
that ship newer Qt that comes with new features and bug fixes. The
interface resource files format is not backwards compatible, so it's a
constant pain to make sure that things still work on older
distributions.
No developers use RHEL 5 anymore, so they just don't care whether it
still works there or not.

But RHEL 5 is still the latest RedHat production release. It's gotten
quite old, I admit, and am eagerly awaiting RHEL 6. But we've seen
similar nuttiness with Subversion on both RHEL 5 and especially on
RHEL 4. If you want people in business/production environments to use
a tool, then it helps if it will compile there.

In fact, the Subversion .spec file has some useful configuration
differences for RHEL 4 and RHEL 5. Perhaps the VLC .spec could do
something differently for RHEL 5?

I started changing and backporting the failing QT4 code, but stopped
again. I guess the code was changed for a reason and I have no clue
what impact changing the code from Qt 4.4.0 back to Qt 4.2.1 code
(from vlc 0.9.8).

This is something I did for SMPlayer when I was still using CentOS for
multimedia and wanted a decent recent mplayer front-end. It's a heroic
effort and you need some expertise.
If you want to go this route I'd rather had a look at 0.9.9a instead.
I think the most practical solution would be in fact to come up with
static builds of VLC against latest Qt.

Ouch. That's generally something to avoid. It's done for a few small
components of Subversion, like SQLite, to avoid that kind of system
library issue.

Then, we would be able to switch all the packages that require newer Qt
to buildrequire this package and statically link against its libraries,
which will be kind of Qt backporting framework.

That's a big indeavor, providing all the system components in newer
versions. I've seen people try that stunt, but it usually breaks down
pretty fast because they wind up failing ot update speficic
components.

One thinig people do is build a separate, slightly different named
package. For example, "gcc-4.x" is released in parallel with gcc-3.x
with the name "gcc4-4.x".

However, I don't have time and energy do mess with it. I don't need it
anymore for myself and I'm not gonna get paid for it.
If you want to have a go at it I wish you best of luck... :-)

Agreed, it's a lot of work.

[Yury V. Zaytsev]

Post by Nico Kadel-Garcia
But RHEL 5 is still the latest RedHat production release. It's gotten
quite old, I admit, and am eagerly awaiting RHEL 6. But we've seen
similar nuttiness with Subversion on both RHEL 5 and especially on
RHEL 4. If you want people in business/production environments to use
a tool, then it helps if it will compile there.

You are telling this to me? :-)
You'd rather explain this to VLC developers.

Post by Nico Kadel-Garcia
In fact, the Subversion .spec file has some useful configuration
differences for RHEL 4 and RHEL 5. Perhaps the VLC .spec could do
something differently for RHEL 5?

No. Unless you want a command-line interface only. Which is probably
worse than 0.9.9a.

Post by Nico Kadel-Garcia
One thinig people do is build a separate, slightly different named
package. For example, "gcc-4.x" is released in parallel with gcc-3.x
with the name "gcc4-4.x".

It is impossible to make a parallel-installable version of qt4. At least
not without help from Redhat.

[Pavel Kankovsky]

Post by Yury V. Zaytsev
It is impossible to make a parallel-installable version of qt4. At least
not without help from Redhat.

Really? qt4 packages in RHEL5 are built with --prefix=/usr/lib/qt4
and almost everything is put there. What makes it impossible to build
another instance of Qt4 with different prefix and perhaps a small
discriminator in sonames?

[Pavel Kankovsky]

Post by Yury V. Zaytsev
1) pkgconfig files installed in /usr/lib/pkgconfig

Put them elsewhere and use PKG_CONFIG_PATH when you need them.

Post by Yury V. Zaytsev
2) symlinks to the libraries

What symlinks? Do you mean things like libQtCore.so.4 (ie. the soname)
pointing at libQtCore.so.4.2.1 (ie. the real filename)? If the new version
ABI is not upward compatible with the old version bundled in the distro
but the new version builds with the same sonames by default then the right
solution is to change the soname of the new version.

Post by Yury V. Zaytsev
This all looks very very dirty to me and the static solution is way much
cleaner, it's just that one needs time to implement it properly.

It does not scale up very well, IMHO.

[Pavel Kankovsky]

Post by Yury V. Zaytsev
Yep. No, usually the ABI is not upward compatible.

Hmm... it is probably compatible (or is supposed to be) in this case
at least up to 4.4.3.
<http://qt.nokia.com/developer/changes/changes-4.4.3> says:
"Applications compiled for 4.0, 4.1, 4.2, and 4.3 will continue to run
with 4.4."

Post by Yury V. Zaytsev
I am not familiar with dynamically linked libraries management on Linux.
What do you mean by "change the soname"? Shall I just rename the so to
libQtCore.so.4.5.4 and remove the synlinks?

ELF dynamic libraries include their "true names" called "soname" (I guess
it stands for "shared object name") in their .dynamic section.

When you link a program with a dynamic library using "-llibrary" the
linker finds "library.so", reads its soname, and adds dependency to the
soname (rather than to "library.so") to the resulting executable file.

A dynamic library having a certain soname is supposed to be binary
compatible with any program depending on the same soname in the sense that
either the program works correctly or it fails to start due to missing
symbols.

A common convention is to use "library.so.1" (where 1 is the generation of
ABI) as a soname and "library.so.1.2.3" (where 1.2.3 is the version of the
library) as a filename, and to let ldconfig symlink soname to filename.

Post by Yury V. Zaytsev

Post by Pavel Kankovsky
It does not scale up very well, IMHO.

Oh really? What would be the potential problems that I'd face?

Qt is a big library. Much bigger than SQLite or libcurl. You'd get
1. bloated source packages, 2. slow rebuild times, and 3. bloated binary
packages if you bundled a private copy of Qt with every package needing
it.

Issues 1 and 2 might be eliminated if there was a standalone
static-library-only devel package of Qt (and perhaps a small runtime
package if any data files are needed).

[Nico Kadel-Garcia]

Date: Mon, 14 Jun 2010 11:45:13 +0200
From: "Yury V. Zaytsev" <yury at shurup.com>
Subject: Re: QRe: [suggest] please update libdvbpsi
To: arnebjarne72 at hotmail.com
Cc: suggest at lists.rpmforge.net
Message-ID: <1276508713.7686.35.camel at mypride>
Content-Type: text/plain
Hi!

I can compile VLC without the Qt4 GUI, making cvlc work.

The reason is very simple: the developers migrate to newer distributions
that ship newer Qt that comes with new features and bug fixes. The
interface resource files format is not backwards compatible, so it's a
constant pain to make sure that things still work on older
distributions.
No developers use RHEL 5 anymore, so they just don't care whether it
still works there or not.

But RHEL 5 is still the latest RedHat production release. It's gotten
quite old, I admit, and am eagerly awaiting RHEL 6. But we've seen
similar nuttiness with Subversion on both RHEL 5 and especially on
RHEL 4. If you want people in business/production environments to use
a tool, then it helps if it will compile there.

In fact, the Subversion .spec file has some useful configuration
differences for RHEL 4 and RHEL 5. Perhaps the VLC .spec could do
something differently for RHEL 5?

I started changing and backporting the failing QT4 code, but stopped
again. I guess the code was changed for a reason and I have no clue
what impact changing the code from Qt 4.4.0 back to Qt 4.2.1 code
(from vlc 0.9.8).

This is something I did for SMPlayer when I was still using CentOS for
multimedia and wanted a decent recent mplayer front-end. It's a heroic
effort and you need some expertise.
If you want to go this route I'd rather had a look at 0.9.9a instead.
I think the most practical solution would be in fact to come up with
static builds of VLC against latest Qt.

Ouch. That's generally something to avoid. It's done for a few small
components of Subversion, like SQLite, to avoid that kind of system
library issue.

Then, we would be able to switch all the packages that require newer Qt
to buildrequire this package and statically link against its libraries,
which will be kind of Qt backporting framework.

That's a big indeavor, providing all the system components in newer
versions. I've seen people try that stunt, but it usually breaks down
pretty fast because they wind up failing ot update speficic
components.

One thinig people do is build a separate, slightly different named
package. For example, "gcc-4.x" is released in parallel with gcc-3.x
with the name "gcc4-4.x".

However, I don't have time and energy do mess with it. I don't need it
anymore for myself and I'm not gonna get paid for it.
If you want to have a go at it I wish you best of luck... :-)

Agreed, it's a lot of work.

[Yury V. Zaytsev]

Post by Nico Kadel-Garcia
But RHEL 5 is still the latest RedHat production release. It's gotten
quite old, I admit, and am eagerly awaiting RHEL 6. But we've seen
similar nuttiness with Subversion on both RHEL 5 and especially on
RHEL 4. If you want people in business/production environments to use
a tool, then it helps if it will compile there.

You are telling this to me? :-)
You'd rather explain this to VLC developers.

Post by Nico Kadel-Garcia
In fact, the Subversion .spec file has some useful configuration
differences for RHEL 4 and RHEL 5. Perhaps the VLC .spec could do
something differently for RHEL 5?

No. Unless you want a command-line interface only. Which is probably
worse than 0.9.9a.

Post by Nico Kadel-Garcia
One thinig people do is build a separate, slightly different named
package. For example, "gcc-4.x" is released in parallel with gcc-3.x
with the name "gcc4-4.x".

It is impossible to make a parallel-installable version of qt4. At least
not without help from Redhat.

[Pavel Kankovsky]

Post by Yury V. Zaytsev
It is impossible to make a parallel-installable version of qt4. At least
not without help from Redhat.

Really? qt4 packages in RHEL5 are built with --prefix=/usr/lib/qt4
and almost everything is put there. What makes it impossible to build
another instance of Qt4 with different prefix and perhaps a small
discriminator in sonames?

[Pavel Kankovsky]

Post by Yury V. Zaytsev
1) pkgconfig files installed in /usr/lib/pkgconfig

Put them elsewhere and use PKG_CONFIG_PATH when you need them.

Post by Yury V. Zaytsev
2) symlinks to the libraries

What symlinks? Do you mean things like libQtCore.so.4 (ie. the soname)
pointing at libQtCore.so.4.2.1 (ie. the real filename)? If the new version
ABI is not upward compatible with the old version bundled in the distro
but the new version builds with the same sonames by default then the right
solution is to change the soname of the new version.

Post by Yury V. Zaytsev
This all looks very very dirty to me and the static solution is way much
cleaner, it's just that one needs time to implement it properly.

It does not scale up very well, IMHO.

[Pavel Kankovsky]

Post by Yury V. Zaytsev
Yep. No, usually the ABI is not upward compatible.

Hmm... it is probably compatible (or is supposed to be) in this case
at least up to 4.4.3.
<http://qt.nokia.com/developer/changes/changes-4.4.3> says:
"Applications compiled for 4.0, 4.1, 4.2, and 4.3 will continue to run
with 4.4."

Post by Yury V. Zaytsev
I am not familiar with dynamically linked libraries management on Linux.
What do you mean by "change the soname"? Shall I just rename the so to
libQtCore.so.4.5.4 and remove the synlinks?

ELF dynamic libraries include their "true names" called "soname" (I guess
it stands for "shared object name") in their .dynamic section.

When you link a program with a dynamic library using "-llibrary" the
linker finds "library.so", reads its soname, and adds dependency to the
soname (rather than to "library.so") to the resulting executable file.

A dynamic library having a certain soname is supposed to be binary
compatible with any program depending on the same soname in the sense that
either the program works correctly or it fails to start due to missing
symbols.

A common convention is to use "library.so.1" (where 1 is the generation of
ABI) as a soname and "library.so.1.2.3" (where 1.2.3 is the version of the
library) as a filename, and to let ldconfig symlink soname to filename.

Post by Yury V. Zaytsev

Post by Pavel Kankovsky
It does not scale up very well, IMHO.

Oh really? What would be the potential problems that I'd face?

Qt is a big library. Much bigger than SQLite or libcurl. You'd get
1. bloated source packages, 2. slow rebuild times, and 3. bloated binary
packages if you bundled a private copy of Qt with every package needing
it.

Issues 1 and 2 might be eliminated if there was a standalone
static-library-only devel package of Qt (and perhaps a small runtime
package if any data files are needed).

[Nico Kadel-Garcia]

Date: Mon, 14 Jun 2010 11:45:13 +0200
From: "Yury V. Zaytsev" <yury at shurup.com>
Subject: Re: QRe: [suggest] please update libdvbpsi
To: arnebjarne72 at hotmail.com
Cc: suggest at lists.rpmforge.net
Message-ID: <1276508713.7686.35.camel at mypride>
Content-Type: text/plain
Hi!

I can compile VLC without the Qt4 GUI, making cvlc work.

The reason is very simple: the developers migrate to newer distributions
that ship newer Qt that comes with new features and bug fixes. The
interface resource files format is not backwards compatible, so it's a
constant pain to make sure that things still work on older
distributions.
No developers use RHEL 5 anymore, so they just don't care whether it
still works there or not.

But RHEL 5 is still the latest RedHat production release. It's gotten
quite old, I admit, and am eagerly awaiting RHEL 6. But we've seen
similar nuttiness with Subversion on both RHEL 5 and especially on
RHEL 4. If you want people in business/production environments to use
a tool, then it helps if it will compile there.

In fact, the Subversion .spec file has some useful configuration
differences for RHEL 4 and RHEL 5. Perhaps the VLC .spec could do
something differently for RHEL 5?

I started changing and backporting the failing QT4 code, but stopped
again. I guess the code was changed for a reason and I have no clue
what impact changing the code from Qt 4.4.0 back to Qt 4.2.1 code
(from vlc 0.9.8).

This is something I did for SMPlayer when I was still using CentOS for
multimedia and wanted a decent recent mplayer front-end. It's a heroic
effort and you need some expertise.
If you want to go this route I'd rather had a look at 0.9.9a instead.
I think the most practical solution would be in fact to come up with
static builds of VLC against latest Qt.

Ouch. That's generally something to avoid. It's done for a few small
components of Subversion, like SQLite, to avoid that kind of system
library issue.

Then, we would be able to switch all the packages that require newer Qt
to buildrequire this package and statically link against its libraries,
which will be kind of Qt backporting framework.

That's a big indeavor, providing all the system components in newer
versions. I've seen people try that stunt, but it usually breaks down
pretty fast because they wind up failing ot update speficic
components.

One thinig people do is build a separate, slightly different named
package. For example, "gcc-4.x" is released in parallel with gcc-3.x
with the name "gcc4-4.x".

However, I don't have time and energy do mess with it. I don't need it
anymore for myself and I'm not gonna get paid for it.
If you want to have a go at it I wish you best of luck... :-)

Agreed, it's a lot of work.

[Yury V. Zaytsev]

Post by Nico Kadel-Garcia
But RHEL 5 is still the latest RedHat production release. It's gotten
quite old, I admit, and am eagerly awaiting RHEL 6. But we've seen
similar nuttiness with Subversion on both RHEL 5 and especially on
RHEL 4. If you want people in business/production environments to use
a tool, then it helps if it will compile there.

You are telling this to me? :-)
You'd rather explain this to VLC developers.

Post by Nico Kadel-Garcia
In fact, the Subversion .spec file has some useful configuration
differences for RHEL 4 and RHEL 5. Perhaps the VLC .spec could do
something differently for RHEL 5?

No. Unless you want a command-line interface only. Which is probably
worse than 0.9.9a.

Post by Nico Kadel-Garcia
One thinig people do is build a separate, slightly different named
package. For example, "gcc-4.x" is released in parallel with gcc-3.x
with the name "gcc4-4.x".

It is impossible to make a parallel-installable version of qt4. At least
not without help from Redhat.

[Pavel Kankovsky]

Post by Yury V. Zaytsev
It is impossible to make a parallel-installable version of qt4. At least
not without help from Redhat.

Really? qt4 packages in RHEL5 are built with --prefix=/usr/lib/qt4
and almost everything is put there. What makes it impossible to build
another instance of Qt4 with different prefix and perhaps a small
discriminator in sonames?

[Pavel Kankovsky]

Post by Yury V. Zaytsev
1) pkgconfig files installed in /usr/lib/pkgconfig

Put them elsewhere and use PKG_CONFIG_PATH when you need them.

Post by Yury V. Zaytsev
2) symlinks to the libraries

What symlinks? Do you mean things like libQtCore.so.4 (ie. the soname)
pointing at libQtCore.so.4.2.1 (ie. the real filename)? If the new version
ABI is not upward compatible with the old version bundled in the distro
but the new version builds with the same sonames by default then the right
solution is to change the soname of the new version.

Post by Yury V. Zaytsev
This all looks very very dirty to me and the static solution is way much
cleaner, it's just that one needs time to implement it properly.

It does not scale up very well, IMHO.

[Pavel Kankovsky]

Post by Yury V. Zaytsev
Yep. No, usually the ABI is not upward compatible.

Hmm... it is probably compatible (or is supposed to be) in this case
at least up to 4.4.3.
<http://qt.nokia.com/developer/changes/changes-4.4.3> says:
"Applications compiled for 4.0, 4.1, 4.2, and 4.3 will continue to run
with 4.4."

Post by Yury V. Zaytsev
I am not familiar with dynamically linked libraries management on Linux.
What do you mean by "change the soname"? Shall I just rename the so to
libQtCore.so.4.5.4 and remove the synlinks?

ELF dynamic libraries include their "true names" called "soname" (I guess
it stands for "shared object name") in their .dynamic section.

When you link a program with a dynamic library using "-llibrary" the
linker finds "library.so", reads its soname, and adds dependency to the
soname (rather than to "library.so") to the resulting executable file.

A dynamic library having a certain soname is supposed to be binary
compatible with any program depending on the same soname in the sense that
either the program works correctly or it fails to start due to missing
symbols.

A common convention is to use "library.so.1" (where 1 is the generation of
ABI) as a soname and "library.so.1.2.3" (where 1.2.3 is the version of the
library) as a filename, and to let ldconfig symlink soname to filename.

Post by Yury V. Zaytsev

Post by Pavel Kankovsky
It does not scale up very well, IMHO.

Oh really? What would be the potential problems that I'd face?

Qt is a big library. Much bigger than SQLite or libcurl. You'd get
1. bloated source packages, 2. slow rebuild times, and 3. bloated binary
packages if you bundled a private copy of Qt with every package needing
it.

Issues 1 and 2 might be eliminated if there was a standalone
static-library-only devel package of Qt (and perhaps a small runtime
package if any data files are needed).

[Nico Kadel-Garcia]

Date: Mon, 14 Jun 2010 11:45:13 +0200
From: "Yury V. Zaytsev" <yury at shurup.com>
Subject: Re: QRe: [suggest] please update libdvbpsi
To: arnebjarne72 at hotmail.com
Cc: suggest at lists.rpmforge.net
Message-ID: <1276508713.7686.35.camel at mypride>
Content-Type: text/plain
Hi!

I can compile VLC without the Qt4 GUI, making cvlc work.

The reason is very simple: the developers migrate to newer distributions
that ship newer Qt that comes with new features and bug fixes. The
interface resource files format is not backwards compatible, so it's a
constant pain to make sure that things still work on older
distributions.
No developers use RHEL 5 anymore, so they just don't care whether it
still works there or not.

But RHEL 5 is still the latest RedHat production release. It's gotten
quite old, I admit, and am eagerly awaiting RHEL 6. But we've seen
similar nuttiness with Subversion on both RHEL 5 and especially on
RHEL 4. If you want people in business/production environments to use
a tool, then it helps if it will compile there.

In fact, the Subversion .spec file has some useful configuration
differences for RHEL 4 and RHEL 5. Perhaps the VLC .spec could do
something differently for RHEL 5?

I started changing and backporting the failing QT4 code, but stopped
again. I guess the code was changed for a reason and I have no clue
what impact changing the code from Qt 4.4.0 back to Qt 4.2.1 code
(from vlc 0.9.8).

This is something I did for SMPlayer when I was still using CentOS for
multimedia and wanted a decent recent mplayer front-end. It's a heroic
effort and you need some expertise.
If you want to go this route I'd rather had a look at 0.9.9a instead.
I think the most practical solution would be in fact to come up with
static builds of VLC against latest Qt.

Ouch. That's generally something to avoid. It's done for a few small
components of Subversion, like SQLite, to avoid that kind of system
library issue.

Then, we would be able to switch all the packages that require newer Qt
to buildrequire this package and statically link against its libraries,
which will be kind of Qt backporting framework.

That's a big indeavor, providing all the system components in newer
versions. I've seen people try that stunt, but it usually breaks down
pretty fast because they wind up failing ot update speficic
components.

One thinig people do is build a separate, slightly different named
package. For example, "gcc-4.x" is released in parallel with gcc-3.x
with the name "gcc4-4.x".

However, I don't have time and energy do mess with it. I don't need it
anymore for myself and I'm not gonna get paid for it.
If you want to have a go at it I wish you best of luck... :-)

Agreed, it's a lot of work.

[Yury V. Zaytsev]

Post by Nico Kadel-Garcia
But RHEL 5 is still the latest RedHat production release. It's gotten
quite old, I admit, and am eagerly awaiting RHEL 6. But we've seen
similar nuttiness with Subversion on both RHEL 5 and especially on
RHEL 4. If you want people in business/production environments to use
a tool, then it helps if it will compile there.

You are telling this to me? :-)
You'd rather explain this to VLC developers.

Post by Nico Kadel-Garcia
In fact, the Subversion .spec file has some useful configuration
differences for RHEL 4 and RHEL 5. Perhaps the VLC .spec could do
something differently for RHEL 5?

No. Unless you want a command-line interface only. Which is probably
worse than 0.9.9a.

Post by Nico Kadel-Garcia
One thinig people do is build a separate, slightly different named
package. For example, "gcc-4.x" is released in parallel with gcc-3.x
with the name "gcc4-4.x".

It is impossible to make a parallel-installable version of qt4. At least
not without help from Redhat.

[Pavel Kankovsky]

Post by Yury V. Zaytsev
It is impossible to make a parallel-installable version of qt4. At least
not without help from Redhat.

Really? qt4 packages in RHEL5 are built with --prefix=/usr/lib/qt4
and almost everything is put there. What makes it impossible to build
another instance of Qt4 with different prefix and perhaps a small
discriminator in sonames?

[Pavel Kankovsky]

Post by Yury V. Zaytsev
1) pkgconfig files installed in /usr/lib/pkgconfig

Put them elsewhere and use PKG_CONFIG_PATH when you need them.

Post by Yury V. Zaytsev
2) symlinks to the libraries

What symlinks? Do you mean things like libQtCore.so.4 (ie. the soname)
pointing at libQtCore.so.4.2.1 (ie. the real filename)? If the new version
ABI is not upward compatible with the old version bundled in the distro
but the new version builds with the same sonames by default then the right
solution is to change the soname of the new version.

Post by Yury V. Zaytsev
This all looks very very dirty to me and the static solution is way much
cleaner, it's just that one needs time to implement it properly.

It does not scale up very well, IMHO.

[Pavel Kankovsky]

Post by Yury V. Zaytsev
Yep. No, usually the ABI is not upward compatible.

Hmm... it is probably compatible (or is supposed to be) in this case
at least up to 4.4.3.
<http://qt.nokia.com/developer/changes/changes-4.4.3> says:
"Applications compiled for 4.0, 4.1, 4.2, and 4.3 will continue to run
with 4.4."

Post by Yury V. Zaytsev
I am not familiar with dynamically linked libraries management on Linux.
What do you mean by "change the soname"? Shall I just rename the so to
libQtCore.so.4.5.4 and remove the synlinks?

ELF dynamic libraries include their "true names" called "soname" (I guess
it stands for "shared object name") in their .dynamic section.

When you link a program with a dynamic library using "-llibrary" the
linker finds "library.so", reads its soname, and adds dependency to the
soname (rather than to "library.so") to the resulting executable file.

A dynamic library having a certain soname is supposed to be binary
compatible with any program depending on the same soname in the sense that
either the program works correctly or it fails to start due to missing
symbols.

A common convention is to use "library.so.1" (where 1 is the generation of
ABI) as a soname and "library.so.1.2.3" (where 1.2.3 is the version of the
library) as a filename, and to let ldconfig symlink soname to filename.

Post by Yury V. Zaytsev

Post by Pavel Kankovsky
It does not scale up very well, IMHO.

Oh really? What would be the potential problems that I'd face?

Qt is a big library. Much bigger than SQLite or libcurl. You'd get
1. bloated source packages, 2. slow rebuild times, and 3. bloated binary
packages if you bundled a private copy of Qt with every package needing
it.

Issues 1 and 2 might be eliminated if there was a standalone
static-library-only devel package of Qt (and perhaps a small runtime
package if any data files are needed).

[Pavel Kankovsky]

Post by Yury V. Zaytsev

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
Yep. No, usually the ABI is not upward compatible.

Hmm... it is probably compatible (or is supposed to be) in this case
at least up to 4.4.3.

Well, that's true, but we would really want to have at least Qt 4.5 if
not 4.6 for our purposes.

FYI:

Later versions do not advertise backward ABI compatibility with 4.2
explicitly but it does not mean they are not compatible. It seems the
developers intent to maintain ABI compatibility. I have not been able to
find any "official statement" of that intention but one can find notes
like this one in the documentation [1]:

"As with every supported platform, we will strive to maintain application
behavior and binary compatibility throughout the lifetime of the Qt 4.x
series."

I have compared Qt 4.2.1 from CentOS 5.5 with 4.6.2 found installed on
one Gentoo box (I was too lazy to rebuild it) with the ABI compliance
checker [2] and the results [3] are quite good. There are some serious
issues in the report but several of them I inspected manually appear to
be harmless (or even false positives).


[1] <http://doc.qt.nokia.com/4.6/platform-notes-symbian.html>
[2] <http://ispras.linux-foundation.org/index.php/ABI_compliance_checker>
[3] <http://peak.nbox.troja.mff.cuni.cz/Qt4_4.2.1-1_to_4.6.2-gentoo_abi_compat_report.html>

[Pavel Kankovsky]

Post by Yury V. Zaytsev

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
Yep. No, usually the ABI is not upward compatible.

Hmm... it is probably compatible (or is supposed to be) in this case
at least up to 4.4.3.

Well, that's true, but we would really want to have at least Qt 4.5 if
not 4.6 for our purposes.

FYI:

Later versions do not advertise backward ABI compatibility with 4.2
explicitly but it does not mean they are not compatible. It seems the
developers intent to maintain ABI compatibility. I have not been able to
find any "official statement" of that intention but one can find notes
like this one in the documentation [1]:

"As with every supported platform, we will strive to maintain application
behavior and binary compatibility throughout the lifetime of the Qt 4.x
series."

I have compared Qt 4.2.1 from CentOS 5.5 with 4.6.2 found installed on
one Gentoo box (I was too lazy to rebuild it) with the ABI compliance
checker [2] and the results [3] are quite good. There are some serious
issues in the report but several of them I inspected manually appear to
be harmless (or even false positives).


[1] <http://doc.qt.nokia.com/4.6/platform-notes-symbian.html>
[2] <http://ispras.linux-foundation.org/index.php/ABI_compliance_checker>
[3] <http://peak.nbox.troja.mff.cuni.cz/Qt4_4.2.1-1_to_4.6.2-gentoo_abi_compat_report.html>

[Pavel Kankovsky]

Post by Yury V. Zaytsev

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
Yep. No, usually the ABI is not upward compatible.

Hmm... it is probably compatible (or is supposed to be) in this case
at least up to 4.4.3.

Well, that's true, but we would really want to have at least Qt 4.5 if
not 4.6 for our purposes.

FYI:

Later versions do not advertise backward ABI compatibility with 4.2
explicitly but it does not mean they are not compatible. It seems the
developers intent to maintain ABI compatibility. I have not been able to
find any "official statement" of that intention but one can find notes
like this one in the documentation [1]:

"As with every supported platform, we will strive to maintain application
behavior and binary compatibility throughout the lifetime of the Qt 4.x
series."

I have compared Qt 4.2.1 from CentOS 5.5 with 4.6.2 found installed on
one Gentoo box (I was too lazy to rebuild it) with the ABI compliance
checker [2] and the results [3] are quite good. There are some serious
issues in the report but several of them I inspected manually appear to
be harmless (or even false positives).


[1] <http://doc.qt.nokia.com/4.6/platform-notes-symbian.html>
[2] <http://ispras.linux-foundation.org/index.php/ABI_compliance_checker>
[3] <http://peak.nbox.troja.mff.cuni.cz/Qt4_4.2.1-1_to_4.6.2-gentoo_abi_compat_report.html>

[Pavel Kankovsky]

Post by Yury V. Zaytsev

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
Yep. No, usually the ABI is not upward compatible.

Hmm... it is probably compatible (or is supposed to be) in this case
at least up to 4.4.3.

Well, that's true, but we would really want to have at least Qt 4.5 if
not 4.6 for our purposes.

FYI:

Later versions do not advertise backward ABI compatibility with 4.2
explicitly but it does not mean they are not compatible. It seems the
developers intent to maintain ABI compatibility. I have not been able to
find any "official statement" of that intention but one can find notes
like this one in the documentation [1]:

"As with every supported platform, we will strive to maintain application
behavior and binary compatibility throughout the lifetime of the Qt 4.x
series."

I have compared Qt 4.2.1 from CentOS 5.5 with 4.6.2 found installed on
one Gentoo box (I was too lazy to rebuild it) with the ABI compliance
checker [2] and the results [3] are quite good. There are some serious
issues in the report but several of them I inspected manually appear to
be harmless (or even false positives).


[1] <http://doc.qt.nokia.com/4.6/platform-notes-symbian.html>
[2] <http://ispras.linux-foundation.org/index.php/ABI_compliance_checker>
[3] <http://peak.nbox.troja.mff.cuni.cz/Qt4_4.2.1-1_to_4.6.2-gentoo_abi_compat_report.html>

[Pavel Kankovsky]

Post by Yury V. Zaytsev

Post by Pavel Kankovsky

Post by Yury V. Zaytsev
Yep. No, usually the ABI is not upward compatible.

Hmm... it is probably compatible (or is supposed to be) in this case
at least up to 4.4.3.

Well, that's true, but we would really want to have at least Qt 4.5 if
not 4.6 for our purposes.

FYI:

Later versions do not advertise backward ABI compatibility with 4.2
explicitly but it does not mean they are not compatible. It seems the
developers intent to maintain ABI compatibility. I have not been able to
find any "official statement" of that intention but one can find notes
like this one in the documentation [1]:

"As with every supported platform, we will strive to maintain application
behavior and binary compatibility throughout the lifetime of the Qt 4.x
series."

I have compared Qt 4.2.1 from CentOS 5.5 with 4.6.2 found installed on
one Gentoo box (I was too lazy to rebuild it) with the ABI compliance
checker [2] and the results [3] are quite good. There are some serious
issues in the report but several of them I inspected manually appear to
be harmless (or even false positives).


[1] <http://doc.qt.nokia.com/4.6/platform-notes-symbian.html>
[2] <http://ispras.linux-foundation.org/index.php/ABI_compliance_checker>
[3] <http://peak.nbox.troja.mff.cuni.cz/Qt4_4.2.1-1_to_4.6.2-gentoo_abi_compat_report.html>