Re: [blfs-support] libixion cannot find boost thread lib
On 01/28/13 16:57, Randy McMurchy wrote:
Thomas de Roo wrote these words on 01/28/13 09:41 CST:
On 01/28/13 16:33, Randy McMurchy wrote:
configure:16159: $? = 1
configure:16144: re-using the existing conftest.o
configure:16150: g++ -o conftest -g -O2 -D_REENTRANT
-DMDDS_HASH_CONTAINER_BOOST
-I/home/rml/build/libixion_0.3.0/mdds_0.5.4/destdir/usr/local/include -g
-Os -pthread -L/usr/lib conftest.o -lboost_thread -pthread 5
/usr/bin/ld: conftest.o: undefined reference to symbol
'_ZN5boost6system15system_categoryEv'
/usr/bin/ld: note: '_ZN5boost6system15system_categoryEv' is defined in DSO
/usr/lib/libboost_system.so.1.52.0 so try adding it to the linker command
line
/usr/lib/libboost_system.so.1.52.0: could not read symbols: Invalid
operation
collect2: error: ld returned 1 exit status
Where did you get the Makefiles in src and src/libixion?
I do not understand what you mean. I only have Makefile.{in,am} in the source
tree as configure bombed out on me the same as it did for you. It bombs out
before the Makefiles are created. I have not installed this package, I was
only trying to be helpful. In fact, I do not have mdds installed either. I
built it inside the libixion tree and installed to a destdir. You can see the
path for the mdds include files in the snippet above.
What Makefiles are you referring to?
Thank you for your help, it is appreciated a lot! I do have the
mdds-headers installed, and configure finds them, but configure fails to
make the Makefiles in src and src/libixion. It stops with the error:
configure: creating ./config.status
config.status: creating Makefile
config.status: creating libixion.pc
config.status: creating VERSION
config.status: creating include/Makefile
config.status: creating include/ixion/Makefile
config.status: creating include/ixion/hash_container/Makefile
config.status: creating include/ixion/interface/Makefile
config.status: creating misc/libixion.spec
config.status: error: cannot find input file: `src/Makefile.in'
And obviously, make fails:
Making all in src
make[1]: Entering directory `/sources/libixion-git/src'
make[1]: *** No rule to make target `all'. Stop.
make[1]: Leaving directory `/sources/libixion-git/src'
make: *** [all-recursive] Error 1
It looks like the package-maintainer forgot to include some
Makefile.in-files. There are Makefile.am-files. Can they be used to
generate the Makefiles?
Again: thanks for the help, I'm learning here...
Groet,
Thomas
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] libixion cannot find boost thread lib
On 01/29/13 10:52, Armin K. wrote: On 01/29/2013 09:26 AM, Thomas de Roo wrote: Thank you for your help, it is appreciated a lot! I do have the mdds-headers installed, and configure finds them, but configure fails to make the Makefiles in src and src/libixion. It stops with the error: configure: creating ./config.status config.status: creating Makefile config.status: creating libixion.pc config.status: creating VERSION config.status: creating include/Makefile config.status: creating include/ixion/Makefile config.status: creating include/ixion/hash_container/Makefile config.status: creating include/ixion/interface/Makefile config.status: creating misc/libixion.spec config.status: error: cannot find input file: `src/Makefile.in' And obviously, make fails: Making all in src make[1]: Entering directory `/sources/libixion-git/src' make[1]: *** No rule to make target `all'. Stop. make[1]: Leaving directory `/sources/libixion-git/src' make: *** [all-recursive] Error 1 It looks like the package-maintainer forgot to include some Makefile.in-files. There are Makefile.am-files. Can they be used to generate the Makefiles? Again: thanks for the help, I'm learning here... Groet, Thomas Use autoreconf -fi Thanks for all the help. I gave up. :( After I managed to get through the ./configure phase (I had to tweak the Makefile.am to produce working Makefile.in files), make stops at errors in the libixion-code. I tried the latest version from the git-repository, with the same result. Google couldn't help, so I guess I'm trying to be too bleeding edge here. I'll wait a little and try the LibreOffice 4 later again, for now I'll stick with 3.6. That doesn't have liborcus as a dependency, so no libixion needed. When someone succeeds at installing LibreOffice 4, I'd like to know how ;) Groet, Thomas -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] System settings - network connections
On Monday 28 January 2013 18:00:49 Armin K. wrote: Hi, I wrote a message yesterday with the asked files ( extract ) daemon.log and sys.log. However, the message was stopped for moderator aproval, as the attached files seem to be longer as allowed. Perhaps you can fix this ? Regards, Edgar -- Dr.-Ing. Edgar Alwers edgaralw...@gmx.de GPG Key ID:AD5C6F70 -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Wicd-1.7.2.4
I have built Wicd-1.7.2.4 and wlan is working now ok. A couple of points. 1) I applied the fix return s.translate(None, table) outlined here https://bbs.archlinux.org/viewtopic.php?pid=1097401 for wicd-gtk to work. I don't see this mentioned in the book? 2) There are complaints during compilation about translations and the install fails at the end. It doesn't stop it working though. I think this is due to the absence of the 'optional' Babel. Cheers. Paul Clark -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] libixion cannot find boost thread lib
Thomas de Roo wrote these words on 01/29/13 05:13 CST: Thanks for all the help. I gave up. :( After I managed to get through the ./configure phase (I had to tweak the Makefile.am to produce working Makefile.in files), make stops at errors in the libixion-code. I tried the latest version from the git-repository, with the same result. Just for the record, I found a libixion-0.3.0.tar.gz tarball somewhere (don't remember where, but I now have it). It only had an autogen.sh file which produced configure and all the Makefile.in files. Then LDFLAGS=-lboost_system ./configure make make check (all tests pass) make install No problems. -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 08:13:00 up 54 days, 18:12, 1 user, load average: 0.02, 0.02, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] System settings - network connections
Dana 29.1.2013 12:27, Dr.-Ing. Edgar Alwers je napisao: On Monday 28 January 2013 18:00:49 Armin K. wrote: Hi, I wrote a message yesterday with the asked files ( extract ) daemon.log and sys.log. However, the message was stopped for moderator aproval, as the attached files seem to be longer as allowed. Perhaps you can fix this ? Regards, Edgar I think you got that because logs were too big. Compress them using xz daemon.log sys.log and try sending them again. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] firefox-18.0.1 : system jpeg considered harmful
I've upgraded to firefox-18.0.1 on one machine (x86_64, radeon r600 video chipset), after building nasm and turbo jpeg. Everything was fine, apart from an absence of jpegs. Some pages seemed to render ok, others had either white or grey areas where an image should be, e.g. news.google.co.uk had framed white rectangles instead of thumbnails, and youtube thumbnails were also grey. I know Fernando reported something similar in the firefox ticket (#3658), so I'm wondering if the problem is common to certain video hardware, or perhaps it's an x86_64 issue ? I also had a debian patch from iceweasel to use system cairo (they patch one file in firefox, instead of patching cairo), so I've now been through a few builds to try to track the problem down. After the second build I remembered that I had a jpeg in ~/ on this machine : using File - Open from firefox gave me a thumbnail when selecting the file, but when it opened I had a grey rectangle instead of the image. For once, I had changed my log directory names across the builds, so the rebuilds weren't overwriting the previous logs. I wondered if nasm was still needed (if I wasn't going to build jpeg turbo in the upgrade, did firefox need nasm ?), so I looked at the logs. The only references to nasm were parameters passed to yasm when building [ -rnasm -pnasm ], so I wondered if yasm could build libjpeg-turbo-1.2.1 : the answer is that it can, and the .so is a bit smaller. Unfortunately the resulting firefox was no better, although my local jpeg now opened as a white rectangle instead of grey. In another build I proved that the debian system cairo patch is not causing any obvious problems (some playbacks on youtube still fail, so I'm not sure if it is a good idea - but jpegs are fine with the version shipped in firefox, whether or not I use debian's patch). So for the moment I'm using the shipped jpeg-turbo in firefox (which builds v6b, not v8). Call me grumpy (I much prefer system libraries). If the problem is widespread, I think we should mention it. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] libixion cannot find boost thread lib
On 01/28/2013 03:53 PM, Thomas de Roo wrote: On my way to LibreOffice 4, When you have the libixion problem fixed, you might want to have a look at my issues building LO 4 in an environment almost, but not entirely unlike LFS+BLFS: http://lists.freedesktop.org/archives/libreoffice/2013-January/044460.html http://lists.freedesktop.org/archives/libreoffice/2013-January/044896.html /Henrik -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful
On 01/29/2013 04:57 PM, Ken Moffat wrote: I've upgraded to firefox-18.0.1 on one machine (x86_64, radeon r600 video chipset), after building nasm and turbo jpeg. Everything was fine, apart from an absence of jpegs. Some pages seemed to render ok, others had either white or grey areas where an image should be, e.g. news.google.co.uk had framed white rectangles instead of thumbnails, and youtube thumbnails were also grey. I know Fernando reported something similar in the firefox ticket (#3658), so I'm wondering if the problem is common to certain video hardware, or perhaps it's an x86_64 issue ? I also had a debian patch from iceweasel to use system cairo (they patch one file in firefox, instead of patching cairo), so I've now been through a few builds to try to track the problem down. After the second build I remembered that I had a jpeg in ~/ on this machine : using File - Open from firefox gave me a thumbnail when selecting the file, but when it opened I had a grey rectangle instead of the image. For once, I had changed my log directory names across the builds, so the rebuilds weren't overwriting the previous logs. I wondered if nasm was still needed (if I wasn't going to build jpeg turbo in the upgrade, did firefox need nasm ?), so I looked at the logs. The only references to nasm were parameters passed to yasm when building [ -rnasm -pnasm ], so I wondered if yasm could build libjpeg-turbo-1.2.1 : the answer is that it can, and the .so is a bit smaller. Unfortunately the resulting firefox was no better, although my local jpeg now opened as a white rectangle instead of grey. In another build I proved that the debian system cairo patch is not causing any obvious problems (some playbacks on youtube still fail, so I'm not sure if it is a good idea - but jpegs are fine with the version shipped in firefox, whether or not I use debian's patch). So for the moment I'm using the shipped jpeg-turbo in firefox (which builds v6b, not v8). Call me grumpy (I much prefer system libraries). If the problem is widespread, I think we should mention it. ĸen Odd. I did notice that sometimes jpeg image loading is a bit slow - white rectangles here. But they seem to load when you scroll a bit down through them. Youtube works fine here, no problems. I don't know with which assembler was mine version built, but everything seems to work. Image stuff is specific to one site only, with lot of images on one page ... Intel hardware here, so I can't confirm if it's hardware specific. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] System settings - network connections
On 01/29/2013 12:27 PM, Dr.-Ing. Edgar Alwers wrote: On Monday 28 January 2013 18:00:49 Armin K. wrote: Hi, I wrote a message yesterday with the asked files ( extract ) daemon.log and sys.log. However, the message was stopped for moderator aproval, as the attached files seem to be longer as allowed. Perhaps you can fix this ? Regards, Edgar Alright, I guess Bruce let them through. I noticed that your wireless connection is being set up before NetworkManager takes over. dhcpcd is trying to start on it, but I don't know if it succeeds ... Do you have /etc/sysconfig/ifconfig.wlan0 ? If you do, can you try renaming it and then restarting NetworkManager ... If it still fails, I'd recommend that you install wpa_supplicant (With D-Bus interface) even if you don't have Wireless Security enabled on your network. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful
--- Em ter, 29/1/13, Ken Moffat escreveu:
De: Ken Moffat
Assunto: [blfs-support] firefox-18.0.1 : system jpeg considered harmful
Para:
Data: Terça-feira, 29 de Janeiro de 2013, 12:57
I've upgraded to firefox-18.0.1 on
one machine (x86_64, radeon r600
video chipset), after building nasm and turbo jpeg.
Everything was
fine, apart from an absence of jpegs. Some pages
seemed to render
ok, others had either white or grey areas where an image
should be,
e.g. news.google.co.uk had framed white rectangles instead
of
thumbnails, and youtube thumbnails were also grey.
I know Fernando reported something similar in the firefox
ticket
(#3658), so I'm wondering if the problem is common to
certain video
hardware, or perhaps it's an x86_64 issue ?
...
After
the second build I remembered that I had a jpeg in ~/ on
this
machine : using File - Open from firefox gave me a
thumbnail when
selecting the file, but when it opened I had a grey
rectangle
instead of the image.
I had these problems.
...
So for the moment I'm using the shipped jpeg-turbo in
firefox
(which builds v6b, not v8). Call me grumpy (I much
prefer system
libraries). If the problem is widespread, I think we
should mention
it.
ĸen
Hi, ĸen
[I am reading the log of the strip everything just finished, so, do not
have all I need to answer, but perhaps I have enough.]
Yes, I solved it. Took me a while. Everything worked after I completely
removed /usr/lib/libjpeg.so* and links to them (removed also libjpeg.la
and libjpeg.a, but I believe you do not have these) and reinstalled
libjpeg-turbo (no need to reinstall any of the mozillas, if they have
been buit with system jpeg). I had libjpeg.so.8.1.something and think
this was the source of the problems.
Now, I have (I am in another host, performed, as I said, a strip
everything in LFS):
$ ls -l /mnt/LFS/usr/lib/libjpeg.*
-rw-r--r-- 1 root root 445424 Jan 21 12:49 /mnt/LFS/usr/lib/libjpeg.a
-rwxr-xr-x 1 root root784 Jan 21 12:49 /mnt/LFS/usr/lib/libjpeg.la
lrwxrwxrwx 1 root root 16 Jan 21 12:49 /mnt/LFS/usr/lib/libjpeg.so -
libjpeg.so.8.0.2
lrwxrwxrwx 1 root root 16 Jan 21 12:49 /mnt/LFS/usr/lib/libjpeg.so.8 -
libjpeg.so.8.0.2
-rwxr-xr-x 1 root root 365069 Jan 21 12:49 /mnt/LFS/usr/lib/libjpeg.so.8.0.2
One of the links libjpeg.so or libjpeg.so.8 was pointing to the old
library, and just relinking did not solve. I removed with paco -r
libjepg-${old-version}, perhaps you will need to check the old
installed files to remove, if removing just the old libraries is not
enough. I do not know what to do if you have libjpeg older than 8 and
if these interfere too.
It is a pleasure if I can help who has helped me so many times.
[]s,
Fernando
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] Stripping
This system is stripped and working! Probably no problem, if it works
now.
Thank you all who helped me.
Reply in line, below.
--- Em seg, 28/1/13, DJ Lucas escreveu:
De: DJ Lucas
Assunto: Re: [blfs-support] Stripping
Para:
Data: Segunda-feira, 28 de Janeiro de 2013, 22:09
On 01/28/2013 10:54 AM, Randy
McMurchy wrote:
Fernando de Oliveira wrote these words on 01/28/13
10:41 CST:
Forwarded from the BLFS Book Maintenance List
list.
Sorry for top posting.
Thanks, Randy.
Though essentially the same thing Bruce said, here is
what I do at the
completion of LFS. Simply modify the log file locations
and include any other
directories you wish and you may like the results:
Randy, I have used only these you listed. Perhaps later...
du -sch {,usr/}{sbin,bin} \
home/rml/build/Logs/LFS_System/Post-Installation/strip-bin.log
21
echo \
home/rml/build/Logs/LFS_System/Post-Installation/strip-bin.log
find sbin bin usr/sbin usr/bin -type f -exec strip
--strip-all --preserve-dates {} \; \
home/rml/build/Logs/LFS_System/Post-Installation/strip-bin.log
21
Good that there is no slash in the beginning, so it is assumed you are
not running the system to be stripped.
echo \
home/rml/build/Logs/LFS_System/Post-Installation/strip-bin.log
du -sch {,usr/}{sbin,bin} \
home/rml/build/Logs/LFS_System/Post-Installation/strip-bin.log
21
cat home/rml/build/Logs/LFS_System/Post-Installation/strip-bin.log
| \
grep -v File format not
recognized
du -sch {,usr/}lib \
home/rml/build/Logs/LFS_System/Post-Installation/strip-lib.log
21
echo \
home/rml/build/Logs/LFS_System/Post-Installation/strip-lib.log
find lib usr/lib -type f -exec strip --strip-debug
--preserve-dates {} \; \
home/rml/build/Logs/LFS_System/Post-Installation/strip-lib.log
21
echo \
home/rml/build/Logs/LFS_System/Post-Installation/strip-lib.log
du -sch {,usr/}lib \
home/rml/build/Logs/LFS_System/Post-Installation/strip-lib.log
21
cat home/rml/build/Logs/LFS_System/Post-Installation/strip-lib.log
| \
grep -v File format not
recognized
I have only modified the log files and added some other commands for
statistics, some after Bruce. Also, logged in k, not h (du).
Just FYI, I ran across this comment in Arch's PKGBUILD for
glibc (which
I've not verified, and blindly followed):
# Do not strip the
following files for improved debugging support
# (improved as in
not breaking gdb and valgrind...):
# ld-${pkgver}.so
# libc-${pkgver}.so
# libpthread-${pkgver}.so
# libthread_db-1.0.so
Now, as to how useful that actually is in practice, I can't
honestly see
a need being that everything else is already lacking...
Anyway, --strip-debug for static libs, --strip-unneeded for
shared libs,
and --strip-all for executable files is what is default for
makepkg (and
coincidentally is what I have stuck with for a while).
Thanks, DJ.
I have a xz file backing up these four, but they seem not to have
been touched, perhaps already stripped in LFS build.
In another post, Bruce wrote, replying to Fernando:
I
still think (IMHO) that a small paragraph about it
would be helpful,
probably in Notes on Building Software, if it does
not deserve a
page. Those LFS pages could be referred to as could
that page
I have no problem with adding that. I don't think it
rises to the point
where an entire page is needed. A section in 'Notes on
Building
Software' is easy enough. Why don't you create a
ticket so we don't forget.
Thanks, Bruce.
Ticket created. Left for you to decide if priority should be low.
http://www.technovelty.org/linux/stripping-shared-libraries.html
That seems to be a good external reference too.
strip-bin totalseconds: 30
strip-lib totalseconds: 188
Totalseconds: 218
USED_AFTER - USED_BEFORE = -161340 (bin)
USED_AFTER - USED_BEFORE = -626516 (lib)
So, about 770M economy in space. Not much, but enough to really use
strip from time to time.
Thank you very much again (BDR).
Have to turn off all machines now.
[]s,
Fernando
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful
Found the file. I had (after many installs, without remove): -rw-r--r-- 1 root root 448148 Jan 21 12:47 /usr/lib/libjpeg.a -rwxr-xr-x 1 root root784 Jan 21 12:47 /usr/lib/libjpeg.la lrwxrwxrwx 1 root root 16 Jan 21 12:47 /usr/lib/libjpeg.so - libjpeg.so.8.0.2 lrwxrwxrwx 1 root root 16 Jan 21 12:47 /usr/lib/libjpeg.so.8 - libjpeg.so.8.4.0 -rwxr-xr-x 1 root root 367352 Jan 21 12:47 /usr/lib/libjpeg.so.8.0.2 -rwxr-xr-x 1 root root 926875 Jan 21 12:46 /usr/lib/libjpeg.so.8.4.0 Now I have: $ ls -l /usr/lib/libjpeg.* -rw-r--r-- 1 root root 445424 Jan 21 12:49 /usr/lib/libjpeg.a -rwxr-xr-x 1 root root784 Jan 21 12:49 /usr/lib/libjpeg.la lrwxrwxrwx 1 root root 16 Jan 21 12:49 /usr/lib/libjpeg.so - libjpeg.so.8.0.2 lrwxrwxrwx 1 root root 16 Jan 21 12:49 /usr/lib/libjpeg.so.8 - libjpeg.so.8.0.2 -rwxr-xr-x 1 root root 365069 Jan 21 12:49 /usr/lib/libjpeg.so.8.0.2 So, it was libjpeg.so.8.4.0 and the symlink libjpeg.so.8 which were interfering. Old removed: jpegsrc.v8d New installed: libjpeg-turbo-1.2.1 []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful
On Tue, Jan 29, 2013 at 05:43:32PM +0100, Armin K. wrote: Odd. I did notice that sometimes jpeg image loading is a bit slow - LOL - turbo for slow white rectangles here. But they seem to load when you scroll a bit down through them. Youtube works fine here, no problems. I don't know with which assembler was mine version built, but everything seems to work. Looking at my logs, libjpeg-turbo (system version) seems to use nasm if it finds it - otherwise it will look for nasmw and then yasm (which is needed to build libvpx, so I don't know if it checks for anything after that). Youtube was essentially unusable when I tried my first build - click on a grey thumbnail with no idea if it was likely to be relevant to my search. Seemed to play as well as in previous versions. I'm not sure if scrolling would have helped - the pages seemed so broken that I didn't try scrolling down. Image stuff is specific to one site only, with lot of images on one page ... Intel hardware here, so I can't confirm if it's hardware specific. Certainly the problematic web pages had a lot of images. But my local jpeg (the one where the thumbnail was ok but the fullsize [ 800x600, 159KB ] image was blank is not in that category. Thanks for your comments - I might try again on my SandyBridge at some time, but the results were so discouraging that I'm in no rush to do that. I have a suspicion that the build of v8 might be the problem, but testing that will need an ancient system (or breaking all other jpeg users). ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful
On Tue, Jan 29, 2013 at 09:03:18AM -0800, Fernando de Oliveira wrote:
Hi, ĸen
[I am reading the log of the strip everything just finished, so, do not
have all I need to answer, but perhaps I have enough.]
Yes, I solved it. Took me a while. Everything worked after I completely
removed /usr/lib/libjpeg.so* and links to them (removed also libjpeg.la
and libjpeg.a, but I believe you do not have these) and reinstalled
libjpeg-turbo (no need to reinstall any of the mozillas, if they have
been buit with system jpeg). I had libjpeg.so.8.1.something and think
this was the source of the problems.
Now, I have (I am in another host, performed, as I said, a strip
everything in LFS):
$ ls -l /mnt/LFS/usr/lib/libjpeg.*
-rw-r--r-- 1 root root 445424 Jan 21 12:49 /mnt/LFS/usr/lib/libjpeg.a
-rwxr-xr-x 1 root root784 Jan 21 12:49 /mnt/LFS/usr/lib/libjpeg.la
lrwxrwxrwx 1 root root 16 Jan 21 12:49 /mnt/LFS/usr/lib/libjpeg.so -
libjpeg.so.8.0.2
lrwxrwxrwx 1 root root 16 Jan 21 12:49 /mnt/LFS/usr/lib/libjpeg.so.8 -
libjpeg.so.8.0.2
-rwxr-xr-x 1 root root 365069 Jan 21 12:49 /mnt/LFS/usr/lib/libjpeg.so.8.0.2
One of the links libjpeg.so or libjpeg.so.8 was pointing to the old
library, and just relinking did not solve. I removed with paco -r
libjepg-${old-version}, perhaps you will need to check the old
installed files to remove, if removing just the old libraries is not
enough. I do not know what to do if you have libjpeg older than 8 and
if these interfere too.
It is a pleasure if I can help who has helped me so many times.
Intereesting. I have
$ls -l /usr/lib/libjpeg.so*
lrwxrwxrwx 1 root root 16 Jan 29 12:02 /usr/lib/libjpeg.so -
libjpeg.so.8.0.2
lrwxrwxrwx 1 root root 16 Jan 29 12:02 /usr/lib/libjpeg.so.8 -
libjpeg.so.8.4.0
-rwxr-xr-x 1 root root 297681 Jan 29 12:02 /usr/lib/libjpeg.so.8.0.2
-rwxr-xr-x 1 root root 258534 Aug 25 01:14 /usr/lib/libjpeg.so.8.4.0
So anything using libjpeg.so.8 would be using 8.4.0 from jpegsrc
instead of 8.0.2 from libjpeg-turbo. Which means that my testing
of 'display' from ImageMagick was picking up the old version. I
wonder if something in xulrunner links to .so.8 instead of .so ?
That might be interesting enough for me to try testing it (not
tonight, and maybe not tomorrow).
I can easily remake the .so.8 symlink, but I'll need to test some
other stuff if that does fix firefox.
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful
--- Em ter, 29/1/13, Ken Moffat escreveu: De: Ken Moffat Assunto: Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful Para: BLFS Support List Data: Terça-feira, 29 de Janeiro de 2013, 15:50 On Tue, Jan 29, 2013 at 05:43:32PM +0100, Armin K. wrote: Odd. I did notice that sometimes jpeg image loading is a bit slow - LOL - turbo for slow white rectangles here. But they seem to load when you scroll a bit down through them. Youtube works fine here, no problems. I don't know with which assembler was mine version built, but everything seems to work. Looking at my logs, libjpeg-turbo (system version) seems to use nasm if it finds it - otherwise it will look for nasmw and then yasm (which is needed to build libvpx, so I don't know if it checks for anything after that). Youtube was essentially unusable when I tried my first build - click on a grey thumbnail with no idea if it was likely to be relevant to my search. Seemed to play as well as in previous versions. I'm not sure if scrolling would have helped - the pages seemed so broken that I didn't try scrolling down. Image stuff is specific to one site only, with lot of images on one page ... Intel hardware here, so I can't confirm if it's hardware specific. Certainly the problematic web pages had a lot of images. But my local jpeg (the one where the thumbnail was ok but the fullsize [ 800x600, 159KB ] image was blank is not in that category. Thanks for your comments - I might try again on my SandyBridge at some time, but the results were so discouraging that I'm in no rush to do that. I have a suspicion that the build of v8 might be the problem, but testing that will need an ancient system (or breaking all other jpeg users). ĸen -- This was my fear, but then I thought if something breaks, I will just rebuild v8. Turned out that nothing broke: tested to open jpeg images with display, feh, gimp and midori (without rebuilding) and all still run without problems. Youtube also works, but I tested only with adobe flash, not gnash. []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful
Fernando de Oliveira wrote: Found the file. I had (after many installs, without remove): -rw-r--r-- 1 root root 448148 Jan 21 12:47 /usr/lib/libjpeg.a -rwxr-xr-x 1 root root784 Jan 21 12:47 /usr/lib/libjpeg.la lrwxrwxrwx 1 root root 16 Jan 21 12:47 /usr/lib/libjpeg.so - libjpeg.so.8.0.2 lrwxrwxrwx 1 root root 16 Jan 21 12:47 /usr/lib/libjpeg.so.8 - libjpeg.so.8.4.0 -rwxr-xr-x 1 root root 367352 Jan 21 12:47 /usr/lib/libjpeg.so.8.0.2 -rwxr-xr-x 1 root root 926875 Jan 21 12:46 /usr/lib/libjpeg.so.8.4.0 Now I have: $ ls -l /usr/lib/libjpeg.* -rw-r--r-- 1 root root 445424 Jan 21 12:49 /usr/lib/libjpeg.a -rwxr-xr-x 1 root root784 Jan 21 12:49 /usr/lib/libjpeg.la lrwxrwxrwx 1 root root 16 Jan 21 12:49 /usr/lib/libjpeg.so - libjpeg.so.8.0.2 lrwxrwxrwx 1 root root 16 Jan 21 12:49 /usr/lib/libjpeg.so.8 - libjpeg.so.8.0.2 -rwxr-xr-x 1 root root 365069 Jan 21 12:49 /usr/lib/libjpeg.so.8.0.2 So, it was libjpeg.so.8.4.0 and the symlink libjpeg.so.8 which were interfering. You probably don't need the .a or .la files. I have nvidia hardware and don't notice any jpeg related problems: lrwxrwxrwx 16 Jul 1 2012 /usr/lib/libjpeg.so - libjpeg.so.8.4.0 lrwxrwxrwx 16 Jul 1 2012 /usr/lib/libjpeg.so.8 - libjpeg.so.8.4.0 -rwxr-xr-x 1027563 Jul 1 2012 /usr/lib/libjpeg.so.8.4.0 I have not stripped the library. I'm not sure your problem was 8.4.0 as much as having .so - .8.0.2 (used for linking) and so.8 - 8.4.0 (used at run time). -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful
[]s, Fernando --- Em ter, 29/1/13, Fernando de Oliveira fam...@yahoo.com.br escreveu: De: Fernando de Oliveira fam...@yahoo.com.br Assunto: Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful Para: BLFS Support List blfs-support@linuxfromscratch.org Data: Terça-feira, 29 de Janeiro de 2013, 16:20 --- Em ter, 29/1/13, Bruce Dubbs escreveu: De: Bruce Dubbs Assunto: Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful Para: BLFS Support List Data: Terça-feira, 29 de Janeiro de 2013, 16:14 Fernando de Oliveira wrote: Found the file. I had (after many installs, without remove): -rw-r--r-- 1 root root 448148 Jan 21 12:47 /usr/lib/libjpeg.a -rwxr-xr-x 1 root root784 Jan 21 12:47 /usr/lib/libjpeg.la lrwxrwxrwx 1 root root 16 Jan 21 12:47 /usr/lib/libjpeg.so - libjpeg.so.8.0.2 lrwxrwxrwx 1 root root 16 Jan 21 12:47 /usr/lib/libjpeg.so.8 - libjpeg.so.8.4.0 -rwxr-xr-x 1 root root 367352 Jan 21 12:47 /usr/lib/libjpeg.so.8.0.2 -rwxr-xr-x 1 root root 926875 Jan 21 12:46 /usr/lib/libjpeg.so.8.4.0 Now I have: $ ls -l /usr/lib/libjpeg.* -rw-r--r-- 1 root root 445424 Jan 21 12:49 /usr/lib/libjpeg.a -rwxr-xr-x 1 root root784 Jan 21 12:49 /usr/lib/libjpeg.la lrwxrwxrwx 1 root root 16 Jan 21 12:49 /usr/lib/libjpeg.so - libjpeg.so.8.0.2 lrwxrwxrwx 1 root root 16 Jan 21 12:49 /usr/lib/libjpeg.so.8 - libjpeg.so.8.0.2 -rwxr-xr-x 1 root root 365069 Jan 21 12:49 /usr/lib/libjpeg.so.8.0.2 So, it was libjpeg.so.8.4.0 and the symlink libjpeg.so.8 which were interfering. You probably don't need the .a or .la files. I have nvidia hardware and don't notice any jpeg related problems: lrwxrwxrwx 16 Jul 1 2012 /usr/lib/libjpeg.so - libjpeg.so.8.4.0 lrwxrwxrwx 16 Jul 1 2012 /usr/lib/libjpeg.so.8 - libjpeg.so.8.4.0 -rwxr-xr-x 1027563 Jul 1 2012 /usr/lib/libjpeg.so.8.4.0 I have not stripped the library. I'm not sure your problem was 8.4.0 as much as having .so - .8.0.2 (used for linking) and so.8 - 8.4.0 (used at run time). -- Bruce As I wrote in the other post, this was my suspicion too, so I did not undertood why just redoing the symlink did not work. s/did not undertood/did not undertand/ Just remembered: after many *jepg* install/remove and at the same time (better say at the same problem), I had two versions of xulrunner/firefox-18.0.1, one with system jpeg, other with built-in jpeg. So, the same version did not work for one combination and later worked for the final libjpeg-turbo only. []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful
Sorry for last post. At the end of that, you will find the following: I did not undertood why just redoing the symlink did not work. s/did not undertood/did not undertand/ Just remembered: after many *jepg* install/remove and at the same time (better say at the same problem), I had two versions of xulrunner/firefox-18.0.1, one with system jpeg, other with built-in jpeg. So, the same version did not work for one combination and later worked for the final libjpeg-turbo only. []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful
Fernando de Oliveira wrote: Just remembered: after many *jepg* install/remove and at the same time (better say at the same problem), I had two versions of xulrunner/firefox-18.0.1, one with system jpeg, other with built-in jpeg. So, the same version did not work for one combination and later worked for the final libjpeg-turbo only. Well one way to isolate an verify the problem would be to have: lrwxrwxrwx 16 Jan 21 12:49 /usr/lib/libjpeg.so - libjpeg.so.8.0.2 lrwxrwxrwx 16 Jan 21 12:49 /usr/lib/libjpeg.so.8 - libjpeg.so.8.0.2 -rwxr-xr-x 365069 Jan 21 12:49 /usr/lib/libjpeg.so.8.0.2 -rwxr-xr-x ?? Jan 21 12:49 /usr/lib/libjpeg.so.8.4.0 test Then cd /usr/lib ln -sf libjpeg.so.8.4.0 libjpeg.so ln -sf libjpeg.so.8.4.0 libjpeg.so.8 test That should completely verify whether the jpeg version is the problem. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful
--- Em ter, 29/1/13, Bruce Dubbs escreveu: De: Bruce Dubbs Assunto: Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful Para: BLFS Support List Data: Terça-feira, 29 de Janeiro de 2013, 16:43 Fernando de Oliveira wrote: Just remembered: after many *jepg* install/remove and at the same time (better say at the same problem), I had two versions of xulrunner/firefox-18.0.1, one with system jpeg, other with built-in jpeg. So, the same version did not work for one combination and later worked for the final libjpeg-turbo only. Many that I have written and what I will write in this is from memory, so I could be wrong if my memory is betraying me. Well one way to isolate an verify the problem would be to have: lrwxrwxrwx 16 Jan 21 12:49 /usr/lib/libjpeg.so - libjpeg.so.8.0.2 lrwxrwxrwx 16 Jan 21 12:49 /usr/lib/libjpeg.so.8 - libjpeg.so.8.0.2 -rwxr-xr-x 365069 Jan 21 12:49 /usr/lib/libjpeg.so.8.0.2 -rwxr-xr-x ?? Jan 21 12:49 /usr/lib/libjpeg.so.8.4.0 test This combination did not work. Also tested removing libjpeg.so.8.4.0, again, no success. Then cd /usr/lib ln -sf libjpeg.so.8.4.0 libjpeg.so ln -sf libjpeg.so.8.4.0 libjpeg.so.8 test That, I did only after removing the turbo version and reinstalling the v8. It is what works now. That should completely verify whether the jpeg version is the problem. -- Bruce About the .a and .la. This is another thing I need to understand. Many discussions, here. I will probably tomorrow, move out the ones from libjpeg-turbo and test. Then will start moving out many others, perhaps all, keeping elsewhere, and test. Thanks for telling me that. []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful
Below, some corrections to what I wrote previously. --- Em ter, 29/1/13, Fernando de Oliveira escreveu: De: Fernando de Oliveira Assunto: Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful Para: BLFS Support List Data: Terça-feira, 29 de Janeiro de 2013, 17:04 --- Em ter, 29/1/13, Bruce Dubbs escreveu: De: Bruce Dubbs Assunto: Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful Para: BLFS Support List Data: Terça-feira, 29 de Janeiro de 2013, 16:43 Fernando de Oliveira wrote: Just remembered: after many *jepg* install/remove and at the same time (better say at the same problem), I had two versions of xulrunner/firefox-18.0.1, one with system jpeg, other with built-in jpeg. So, the same version did not work for one combination and later worked for the final libjpeg-turbo only. Many that I have written and what I will write in this is from memory, so I could be wrong if my memory is betraying me. Well one way to isolate an verify the problem would be to have: lrwxrwxrwx 16 Jan 21 12:49 /usr/lib/libjpeg.so - libjpeg.so.8.0.2 lrwxrwxrwx 16 Jan 21 12:49 /usr/lib/libjpeg.so.8 - libjpeg.so.8.0.2 -rwxr-xr-x 365069 Jan 21 12:49 /usr/lib/libjpeg.so.8.0.2 -rwxr-xr-x ?? Jan 21 12:49 /usr/lib/libjpeg.so.8.4.0 test This combination did not work. Also tested removing libjpeg.so.8.4.0, again, no success. Only succeeded after a complete paco remove of jpegsrc.v8d Then cd /usr/lib ln -sf libjpeg.so.8.4.0 libjpeg.so ln -sf libjpeg.so.8.4.0 libjpeg.so.8 test That, I did only after removing the turbo version and reinstalling the v8. It is what works now. Wrong (was written incorrectly, just before sending, tried to correct the verb and got the wrong statement). Should be: It is what worked then (or before), if I recall correctly. []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful
Fernando de Oliveira wrote: About the .a and .la. This is another thing I need to understand. Many discussions, here. .a files have it's contained functions embedded in the executable. It is only used in the link phase of the build process. If used, the executable does not look for the functions at run time. If a program uses a .a library and the library is updated, the program has to be relinked to use it. .la files are 'libtool archive' files. They are ascii and provide information for libtool to find libraries. If the .la file does not exist, the fallback is the default+specified library paths. Sometimes one .la file refers to another and, if missing, causes the build to fail. If all .la files are removed, then the build proceeds normally. AFAIK, the main capabilities that libtool provide is the ability to cross build from one architecture to another. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful
On Tue, Jan 29, 2013 at 02:23:31PM -0600, Bruce Dubbs wrote: AFAIK, the main capabilities that libtool provide is the ability to cross build from one architecture to another. I think its main purpose is to provide usable libraries whatever the *platform* (related to all those tests in configure, for old OS's we've otherwise forgotten about, and for the still-current non-linux OS's such as the BSDs. ISTR that the *how* of linking varies greatly, but that libtool should just be able to do it. On linux, of course, creating libraries is simples and that is why libtool looks like an unnecessary overhead to many people. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] firefox-18.0.1 : system jpeg considered harmful
On Tue, Jan 29, 2013 at 07:07:13PM +, Ken Moffat wrote: On Tue, Jan 29, 2013 at 09:03:18AM -0800, Fernando de Oliveira wrote: Hi, ĸen Missed that part - thanks :) Intereesting. I have $ls -l /usr/lib/libjpeg.so* lrwxrwxrwx 1 root root 16 Jan 29 12:02 /usr/lib/libjpeg.so - libjpeg.so.8.0.2 lrwxrwxrwx 1 root root 16 Jan 29 12:02 /usr/lib/libjpeg.so.8 - libjpeg.so.8.4.0 -rwxr-xr-x 1 root root 297681 Jan 29 12:02 /usr/lib/libjpeg.so.8.0.2 -rwxr-xr-x 1 root root 258534 Aug 25 01:14 /usr/lib/libjpeg.so.8.4.0 So anything using libjpeg.so.8 would be using 8.4.0 from jpegsrc instead of 8.0.2 from libjpeg-turbo. Which means that my testing of 'display' from ImageMagick was picking up the old version. I wonder if something in xulrunner links to .so.8 instead of .so ? That might be interesting enough for me to try testing it (not tonight, and maybe not tomorrow). Well, it was interesting enough that I _did_ try it out tonight, on the same box but with a system from June (so, mostly similar to 7.2). First, it still showed the problem with the system libjpeg using the jpegsrc version for .so.8. [ 8.4.0 instead of 8.0.2 ]. Scrolling, where available, or reloading the page, didn't fix it. The following libs link to libjpeg.so.8 : libdbusservice.so, libmozgnome.so (those are in the components directory of xulrunner), libxpcom.so and libxul.so. Remaking the symlink to 8.0.2 does fix it. Also tested with display and the gimp (exporting to jpeg). All I've got to do now is to add some code to my upgrade script to check if .so and .so.8 point to different places, and fix it when necessary. Many thanks. ĸen, no longer grumpy -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] SSL certificates
On 01/28/2013 05:44 PM, DJ Lucas wrote: I get the same behavior with openssl s_client unless I explicitly set CApath, which makes me wonder if our OpenSSL installation is slightly broken. I'll look into that quick. Oops, already been though this once before. I had forgotten, but this is expected behavior. -- DJ -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
