Hello, guys.
Google Talk Plugin for GMail is not working anymore for me (and others...) because it relies on libssl.so.0.9.8. But for my surprise, the binary GoogletalkPlugin is a 32 bits executable, even for the 64 bits package. It comes right after the original deb package, provided by Google.
To make things short, I tried to "downgrade" the lib32-openssl PKGBUILD to version 0,9,8n. It compiles fine, but the resulting libraries (libcrypto.so.0.9.8 and libssl.so.0.9,8) are ELF64, when they should be ELF32. You can view the PKGBUILD in http://pastebin.com/04xsippr
So, should I need a 32 bits chroot for that? Shouldn't the multilib compiler be enough?
On 10/27/2010 04:47 AM, Denis A. Altoé Falqueto wrote:
Hello, guys.
Google Talk Plugin for GMail is not working anymore for me (and others...) because it relies on libssl.so.0.9.8. But for my surprise, the binary GoogletalkPlugin is a 32 bits executable, even for the 64 bits package. It comes right after the original deb package, provided by Google.
To make things short, I tried to "downgrade" the lib32-openssl PKGBUILD to version 0,9,8n. It compiles fine, but the resulting libraries (libcrypto.so.0.9.8 and libssl.so.0.9,8) are ELF64, when they should be ELF32. You can view the PKGBUILD in http://pastebin.com/04xsippr
So, should I need a 32 bits chroot for that? Shouldn't the multilib compiler be enough?
sorry but if you think that downgrading lib32-openssl will solve this, you are wrong. just get the PKGBUILD from AUR and it would have the right dependencies for it.
https://aur.archlinux.org/packages.php?ID=40056
as you see it has libpng12, openssl-compatibility as dependencies.
On Wed, Oct 27, 2010 at 6:42 AM, Ionuț Bîru ibiru@archlinux.org wrote:
On 10/27/2010 04:47 AM, Denis A. Altoé Falqueto wrote:
Hello, guys.
Google Talk Plugin for GMail is not working anymore for me (and others...) because it relies on libssl.so.0.9.8. But for my surprise, the binary GoogletalkPlugin is a 32 bits executable, even for the 64 bits package. It comes right after the original deb package, provided by Google.
To make things short, I tried to "downgrade" the lib32-openssl PKGBUILD to version 0,9,8n. It compiles fine, but the resulting libraries (libcrypto.so.0.9.8 and libssl.so.0.9,8) are ELF64, when they should be ELF32. You can view the PKGBUILD in http://pastebin.com/04xsippr
So, should I need a 32 bits chroot for that? Shouldn't the multilib compiler be enough?
sorry but if you think that downgrading lib32-openssl will solve this, you are wrong. just get the PKGBUILD from AUR and it would have the right dependencies for it.
https://aur.archlinux.org/packages.php?ID=40056
as you see it has libpng12, openssl-compatibility as dependencies.
Yes, but they are not enough. If you check with readelf -h /opt/google/talkplugin/GoogleTalkPlugin, you'll see that it is a ELF32 binary, and it depends on libssl.so.0.9.8. I could use the package on AUR, but it is not compiled with the the new multilib compiler. I would like to do it in the new right way.
In fact, after searching the forums, I found that calling linux32 make, instead of just make, in the PKGBUILD, generates a ELF32 library. It is working fine in my laptop, but I'll investigate it further.
Any comments are welcome.
On 10/27/2010 05:37 PM, Denis A. Altoé Falqueto wrote:
On Wed, Oct 27, 2010 at 6:42 AM, Ionuț Bîruibiru@archlinux.org wrote:
On 10/27/2010 04:47 AM, Denis A. Altoé Falqueto wrote:
Hello, guys.
Google Talk Plugin for GMail is not working anymore for me (and others...) because it relies on libssl.so.0.9.8. But for my surprise, the binary GoogletalkPlugin is a 32 bits executable, even for the 64 bits package. It comes right after the original deb package, provided by Google.
To make things short, I tried to "downgrade" the lib32-openssl PKGBUILD to version 0,9,8n. It compiles fine, but the resulting libraries (libcrypto.so.0.9.8 and libssl.so.0.9,8) are ELF64, when they should be ELF32. You can view the PKGBUILD in http://pastebin.com/04xsippr
So, should I need a 32 bits chroot for that? Shouldn't the multilib compiler be enough?
sorry but if you think that downgrading lib32-openssl will solve this, you are wrong. just get the PKGBUILD from AUR and it would have the right dependencies for it.
https://aur.archlinux.org/packages.php?ID=40056
as you see it has libpng12, openssl-compatibility as dependencies.
Yes, but they are not enough. If you check with readelf -h /opt/google/talkplugin/GoogleTalkPlugin, you'll see that it is a ELF32 binary, and it depends on libssl.so.0.9.8. I could use the package on AUR, but it is not compiled with the the new multilib compiler. I would like to do it in the new right way.
In fact, after searching the forums, I found that calling linux32 make, instead of just make, in the PKGBUILD, generates a ELF32 library. It is working fine in my laptop, but I'll investigate it further.
Any comments are welcome.
the PKGBULD has the right dependencies for x86_64
if [ "${CARCH}" = 'x86_64' ]; then ARCH='amd64' depends=('alsa-utils' 'lib32-gcc-libs>=4.1.1' 'lib32-libstdc++5' 'glibc>=2.4' 'lib32-glibc>=2.3.4' 'fontconfig>=2.4.0' 'freetype2>=2.3.5' 'libgl' 'glew>=1.5.0' 'glib2>=2.12.0' 'gtk2>=2.12.0' 'libpng12>=1.2.13' 'libstdc++5' 'lib32-libx11' 'lib32-libxt' 'lib32-openssl-compatibility' 'libv4l' 'lib32-libxfixes' 'lib32-zlib') md5sums=('737283cd4e504dc5d3add2cb057bd273')
On Wed, Oct 27, 2010 at 1:05 PM, Ionuț Bîru ibiru@archlinux.org wrote:
the PKGBULD has the right dependencies for x86_64
if [ "${CARCH}" = 'x86_64' ]; then ARCH='amd64' depends=('alsa-utils' 'lib32-gcc-libs>=4.1.1' 'lib32-libstdc++5' 'glibc>=2.4' 'lib32-glibc>=2.3.4' 'fontconfig>=2.4.0' 'freetype2>=2.3.5' 'libgl' 'glew>=1.5.0' 'glib2>=2.12.0' 'gtk2>=2.12.0' 'libpng12>=1.2.13' 'libstdc++5' 'lib32-libx11' 'lib32-libxt' 'lib32-openssl-compatibility' 'libv4l' 'lib32-libxfixes' 'lib32-zlib') md5sums=('737283cd4e504dc5d3add2cb057bd273')
I see, but maybe I dndn't made my point clear. I want to make a lib32-openssl-compatibility, with 32 bits libraries, in my 64 bits environment. I just wanted to know if I really needed a 32 bits chroot or if there would be some way to get that just by using gcc-multilib.
I ended up with a solution, using 'linux32 make'. It produced an ELF32 library as I need. But I don't know if it is the best way. I'll investigate when I have a little time.
On 10/27/2010 06:18 PM, Denis A. Altoé Falqueto wrote:
On Wed, Oct 27, 2010 at 1:05 PM, Ionuț Bîruibiru@archlinux.org wrote:
the PKGBULD has the right dependencies for x86_64
if [ "${CARCH}" = 'x86_64' ]; then ARCH='amd64' depends=('alsa-utils' 'lib32-gcc-libs>=4.1.1' 'lib32-libstdc++5' 'glibc>=2.4' 'lib32-glibc>=2.3.4' 'fontconfig>=2.4.0' 'freetype2>=2.3.5' 'libgl' 'glew>=1.5.0' 'glib2>=2.12.0' 'gtk2>=2.12.0' 'libpng12>=1.2.13' 'libstdc++5' 'lib32-libx11' 'lib32-libxt' 'lib32-openssl-compatibility' 'libv4l' 'lib32-libxfixes' 'lib32-zlib') md5sums=('737283cd4e504dc5d3add2cb057bd273')
I see, but maybe I dndn't made my point clear. I want to make a lib32-openssl-compatibility, with 32 bits libraries, in my 64 bits environment. I just wanted to know if I really needed a 32 bits chroot or if there would be some way to get that just by using gcc-multilib.
I ended up with a solution, using 'linux32 make'. It produced an ELF32 library as I need. But I don't know if it is the best way. I'll investigate when I have a little time.
from what i see from lib32-openssl-compatibility is uing the older openssl package from arm machine and extract it. It doesn't build it and if this was the case, then it will have gcc-multilib as makedepends
On Wed, Oct 27, 2010 at 1:58 PM, Ionuț Bîru ibiru@archlinux.org wrote:
from what i see from lib32-openssl-compatibility is uing the older openssl package from arm machine and extract it. It doesn't build it and if this was the case, then it will have gcc-multilib as makedepends
Exactly. I changed the PKGBUILD to compile with CFLAGS="gcc -m32" and CXX="g++ -m32", according to lots of other PKGBUILDs in the multilib repository. I thought it would be enough to generate a 32 bits library, but it is not.
On 10/27/2010 07:18 PM, Denis A. Altoé Falqueto wrote:
On Wed, Oct 27, 2010 at 1:58 PM, Ionuț Bîruibiru@archlinux.org wrote:
from what i see from lib32-openssl-compatibility is uing the older openssl package from arm machine and extract it. It doesn't build it and if this was the case, then it will have gcc-multilib as makedepends
Exactly. I changed the PKGBUILD to compile with CFLAGS="gcc -m32" and CXX="g++ -m32", according to lots of other PKGBUILDs in the multilib repository. I thought it would be enough to generate a 32 bits library, but it is not.
want to paste your PKGBUILD to look at it?
On Wed, Oct 27, 2010 at 3:29 PM, Ionuț Bîru ibiru@archlinux.org wrote:
want to paste your PKGBUILD to look at it?
I did, it's in the original mail :) But here it is, to save time: http://pastebin.com/04xsippr. If you change lines 37 and 39, appending linux32 at the start of the lines, it will generate ELF32 libraries. The depends and makedepends arrays are not quite right, but I'll try to run namecap on it when I have some time.
On 10/27/2010 09:34 PM, Denis A. Altoé Falqueto wrote:
On Wed, Oct 27, 2010 at 3:29 PM, Ionuț Bîruibiru@archlinux.org wrote:
want to paste your PKGBUILD to look at it?
I did, it's in the original mail :) But here it is, to save time: http://pastebin.com/04xsippr. If you change lines 37 and 39, appending linux32 at the start of the lines, it will generate ELF32 libraries. The depends and makedepends arrays are not quite right, but I'll try to run namecap on it when I have some time.
sorry for the late reply. I was thinking you used the lib32-openssl as model but my assumption was wrong.
lib32-openssl has this for configure: ./Configure linux-elf --prefix=/usr --openssldir=/etc/ssl --libdir=lib32 etc
note the linux-elf option. that is important.
On Fri, Oct 29, 2010 at 11:28 AM, Ionuț Bîru ibiru@archlinux.org wrote:
sorry for the late reply. I was thinking you used the lib32-openssl as model but my assumption was wrong.
lib32-openssl has this for configure: ./Configure linux-elf --prefix=/usr --openssldir=/etc/ssl --libdir=lib32 etc
note the linux-elf option. that is important.
Yes, it worked. Now I'll try to contact the mantainter of the package asking him to update it.
Thanks.
aur-general@lists.archlinux.org