View previous topic :: View next topic |
Author |
Message |
VinzC Watchman
Joined: 17 Apr 2004 Posts: 5098 Location: Dark side of the mood
|
Posted: Mon Aug 20, 2007 7:57 am Post subject: |
|
|
Paapaa wrote: | So why can't the package manager take care of rebuilding packages in these kind of situations? Basically integrating revdep-rebuild to package manager. |
Voltago wrote: | My guess: limited developer time. Perhaps this will come some day, until then a wrapper script around emerge should work fine. |
Limited developer time but also limited developer resources. There are plenty of packages, thousands of libraries. Resolving such conflicts would mean deep inspection of packages and libraries and executables before an ebuild can be written.
This means a considerable amount of time must be spent on each package. Given the limited number of developers this is unlikely to happen, IMHO. And it's not the only way to prevent this situation from happening.
As per my own experience a way out is to compile packages in the exact order they need to. And revdep-rebuild doesn't seem to manage package ordering perfectly, as some have notice. IMHO this is a key feature to enhance.
For instance, recompile pango then tunepimp then gtk+ then other packages. Packages that depend on GTK also have runtime dependencies on other packages that depend on expat. The latter are the ones which should be recompiled in the first place.
Most of our frustration comes from revdep-rebuild - which is the ultimate, last hope tool that we all rely on to fix dependency troubles - failing to resolve broken dependencies in the correct order. I - speaking for myself - can cope with emerge failing to update my system because of broken dependencies. But on the other hand, I have great expectations on revdep-rebuild. I was sad it couldn't fix the problem and I had to rebuild my system with my own hands.
I had time to spend however. I understand many of us are not as comfortable with time issues. But again: Gentoo is meant for the ones who understands the implications of compiling everytime. It's almost like building a new distribution each time there is an update.
If these kinds of troubles have an impact on your timeline, you might want to consider switching to a binary distribution instead, where all these troubles are handled by the developers. _________________ Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739!
Last edited by VinzC on Wed Dec 26, 2007 3:49 pm; edited 1 time in total |
|
Back to top |
|
|
stef Tux's lil' helper
Joined: 23 Jul 2003 Posts: 93
|
Posted: Mon Aug 20, 2007 9:28 am Post subject: revdep-rebuild fails to repair libexpat problems |
|
|
well ... came across the same problems - didn't expect the upgrade of libexpat to break all of my system as emerge does not indicate incompatible abi at all. (as far as i can see)
Ok, well no big problem i thought, as this is just the usual thing to let revdep-rebuild rebuild the neccessary packages.
so i tried a:
Code: |
revdep-rebuild -X --library libexpat.so.0
revdep-rebuild --library libexpat.so.0
revdep-rebuild -X
revdep-rebuild
|
all of which did recompile *some* packages but always failing for example on pango, qt, ...
So i found some hints in the forum to
Code: |
emerge --oneshot fontconfig pango
|
fontconfig built fine, but pango again failed ...
So my conclusion was that probably my only hope would be to do a
to really make sure to have all packages be rebuild (in the right order)
But my problem is that I am on a (not that fast) laptop here and need it. Meaning I can't wait the next 3 days for my system to rebuild without being able to work :/
(and now i have a system where one half is linked against libexpat-2 and the other against libexpat-1 *doh)
So ... as i consider the symlink hack really a bad hack, which in theory shouldnt work, as the libs have different abi, right?
I now came up with the following (which until now works fine with me:)
I did a
Code: |
emerge -v1 "<expat-2"
cp /usr/lib/libexpat.so.0.5.0 /usr/lib/libexpat.so.0.5.0_copy
emerge -v1 expat
mv /usr/lib/libexpat.so.0.5.0_copy /usr/lib/libexpat.so.0.5.0
ln -s /usr/lib/libexpat.so.0.5.0 /usr/lib/libexpat.so.0
|
So now i have both the old version and the new version of libexpat ready. Now the linker should be able to locate the right lib whichever is needed. (or am i missing something here?!)
So far my system works fine - i can continue work and let the system rebuild in the background.
When everything is rebuild i guess it will be save to remove /usr/lib/libexpat.so.0.5.0 and /usr/lib/libexpat.so.0 again.
Any of the dev's having objections agains that way of upgrading?
... i guess this would make the users happy since the system is still usable and packages beeing recompiled should be linking to the new version anyways such that you are able to migrate the system to the new abi.
(a revdep-rebuild --library=libexpat.so.0 should again be enough to do that)
So I'd vote for: keep the old lib when installing the new and inform the user that he/she should do the rebuild to make sure everything works without problems. But just removing the old lib leaving the user with a broken system and telling him the only chance is to rebuild everything is bad (ok, it makes sure he does the rebuild ... but that even might fail as in my case - see above)
Well, that were just my2cents |
|
Back to top |
|
|
VinzC Watchman
Joined: 17 Apr 2004 Posts: 5098 Location: Dark side of the mood
|
Posted: Mon Aug 20, 2007 10:20 am Post subject: Re: I'm usually a Gentoo Fan, BUT.. |
|
|
jonnevers wrote: | I contend, that the KDE 3.5.7 and the expat-2 updates should *not* have occurred at the same time. The version differences in updating both of these packages together is what caused my trouble. |
Voltago wrote: | Quite the reverse. Since many KDE (and Gnome) packages link to expat, it was very practical to stabilize them both at the same time, as you could spare yourself a lot of rebuilds. Worked well enough on several machines for me. What is that version difference problem you allude to? |
I also share your point of view, Voltago. In fact the problem doesn't reside between KDE and expat, IMHO, but in the *order* which packages were upgraded during the first global emerge.
The fact that there are some packages that need other ones that depend on expat (gtk+ requires, IIRC, calls to pango and/or fontconfig modules during the ./configure process, which both depend on expat).
Fixing the order during what I'd call the "master" emerge would have been difficult as it almost requires artificial intelligence at that very particular time. Hence the last chance of fixing the order of packages to merge was revdep-rebuild... and it failed. IMHO a big enhancement is required to the latter as it currently doesn't seem to make the difference between direct and indirect dependencies, if I've understood.
I was able to fix the order myself because I spent a couple of hours staring at my screen when compile errors occured. Maybe I'll be able to determine the correct emerge order in advance the third time... but I have no more than 3 Gentoo machines . _________________ Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
Back to top |
|
|
whkinney n00b
Joined: 03 Feb 2004 Posts: 20
|
Posted: Mon Aug 20, 2007 5:13 pm Post subject: |
|
|
VinzC wrote: |
I had time to spend however. I understand many of us are not as comfortable with time issues. But again: Gentoo is meant for the ones who understands the implications of compiling everytime. It's almost like building a new distribution each time there is an update.
|
That would be well and good if the tools available to do the build actually worked. In the case of expat, portage and revdep-rebuild failed. Miserably. The devs knew about the problem while the library update was still ~x86, but did nothing and released the update into the stable tree anyway.
It's been sad to witness the decline of Gentoo in the time since drobbin's departure from the fantastic distro it once was to the substandard mess it has become. What a waste.
VinzC wrote: |
If these kinds of troubles have an impact on your timeline, you might want to consider switching to a binary distribution instead, where all these troubles are handled by the developers. |
Sounds like an excellent plan. Evidently the Gentoo devs don't have sufficient resources to maintain the distro properly. |
|
Back to top |
|
|
spamspam Apprentice
Joined: 05 Dec 2003 Posts: 153
|
Posted: Mon Aug 20, 2007 6:22 pm Post subject: |
|
|
whkinney wrote: | VinzC wrote: |
... I understand many of us are not as comfortable with time issues. ...
|
... revdep-rebuild failed. Miserably. The devs knew about the problem while the library update was still ~x86, but did nothing and released the update into the stable tree anyway.
|
The problem wasn't the time it takes; it's that it was unplanned downtime that could have happened in a planned manner if expat-2.0.1 had been blocked on <expat-2.0.0 . expat-2.0.0 was blocked on <expat-2.0.0, why wasn't expat-2.0.1?
whkinney wrote: |
VinzC wrote: |
If these kinds of troubles have an impact on your timeline, you might want to consider switching to a binary distribution instead, where all these troubles are handled by the developers. |
Sounds like an excellent plan. Evidently the Gentoo devs don't have sufficient resources to maintain the distro properly. |
I am also considering this. It's certainly not from being a newbie; I've been admining Linux since 1995, running gentoo since 2003, and even have submitted a kernel patch. |
|
Back to top |
|
|
Twist Guru
Joined: 03 Jan 2003 Posts: 414 Location: San Diego
|
Posted: Mon Aug 20, 2007 7:19 pm Post subject: |
|
|
This has seriously shaken my faith in Gentoo. I have been running this distro for years, at work at and at home, across probably ten machines that I use on a pretty regular basis. I am not a novice user, of either Linux in general or Gentoo in particular. However "updates" like this are just disheartening in their difficulty - I realize the devs are not in control of the issues with expat itself, but for crying out loud:
- After years the mechanics of informing a user of a nasty upgrade caveat are still to have the ebuild emit some instructions that most people will never see during first-run (I don't know about anybody else, but I have much better things to do than watch my emerges by hand)
- The stated fix doesn't work, on multiple machines I have (revdep-rebuild simply does not work correctly, even on my bone stable vanilla install)
- Given the above condition, recovery is ugly and incredibly time consuming (eventually I threw in the towel and did an emerge -e system on an affected system, only to find that pango STILL would not emerge afterwards due to an inherited dependency from fontconfig; luckily a user had already discovered this and gave me the hint to emerge fontconfig first then pango)
This change was pervasive and extremely likely to break many installs, given the state of tools to deal with these problems. Yet it was committed to stable anyway. IMHO an entire new release should have come from this change, with appropriate blockage to keep in-use machines from sudden and extended downtime trying to recover from what should have been a plain jane update.
I appreciate the (usual) excellent community response and support evident in this thread. I am a strong proponent of the goals and values represented by Gentoo in general. But in this circumstance, it utterly failed me as a distro. Seriously.
-Twist |
|
Back to top |
|
|
dmitchell Veteran
Joined: 17 May 2003 Posts: 1159 Location: Austin, Texas
|
Posted: Mon Aug 20, 2007 8:07 pm Post subject: |
|
|
KDE users: for me revdep-rebuild failed on the first kde package, citing problems with kde-config. Ultimately I had to emerge fontconfig, qt, and kdelibs before revdep-rebuild succeeded. _________________ Your argument is invalid. |
|
Back to top |
|
|
Bobnoxous Apprentice
Joined: 03 May 2005 Posts: 240
|
Posted: Mon Aug 20, 2007 8:17 pm Post subject: |
|
|
Just to add my experience, I could not get mozilla-firefox to build until I ran:
> revdep-rebuild -X
Adding --library libexpat.so.0 did not work. This sidelined be for a long time. _________________ "The problem with the world is that fools and fanatics are always so sure of themselves while wiser people are so full of doubt."
- Bertrand Russell |
|
Back to top |
|
|
turtles Veteran
Joined: 31 Dec 2004 Posts: 1658
|
Posted: Mon Aug 20, 2007 9:11 pm Post subject: |
|
|
I am wandering my way through this and experiencing some issues with Code: | Calculating dependencies... done!
[ebuild R ] dev-libs/apr-util-1.2.8
|
It seems that revdep-rebuild just wants to keep rebuilding it.
I added a bug in bugzilla 189642 If you think this should have been a blocker add a comment to the bug. I will open a thread in user relations when the bug gets closed as a wont fix.
EDIT: was not closed as a wont fix anyway. _________________ Donate to Gentoo
Last edited by turtles on Tue Aug 21, 2007 5:42 am; edited 1 time in total |
|
Back to top |
|
|
drumgod n00b
Joined: 12 Dec 2003 Posts: 61
|
Posted: Mon Aug 20, 2007 9:27 pm Post subject: |
|
|
turtles wrote: | I am wandering my way through this and experiencing some issues with Code: | Calculating dependencies... done!
[ebuild R ] dev-libs/apr-util-1.2.8
|
It seems that revdep-rebuild just wants to keep rebuilding it... |
"equery list apr-util" will most likely show you that you have apr-util-0.9.12-r1 installed as well. "revdep-rebuild -X" finds the dependency in the older version then re-installs the newer version because of the -X flag... |
|
Back to top |
|
|
turtles Veteran
Joined: 31 Dec 2004 Posts: 1658
|
Posted: Mon Aug 20, 2007 9:57 pm Post subject: |
|
|
drumgod wrote: | turtles wrote: | I am wandering my way through this and experiencing some issues with Code: | Calculating dependencies... done!
[ebuild R ] dev-libs/apr-util-1.2.8
|
It seems that revdep-rebuild just wants to keep rebuilding it... |
"equery list apr-util" will most likely show you that you have apr-util-0.9.12-r1 installed as well. "revdep-rebuild -X" finds the dependency in the older version then re-installs the newer version because of the -X flag... |
Yes Code: | equery list apr-util
[ Searching for package 'apr-util' in all categories among: ]
* installed packages
[I--] [ ] dev-libs/apr-util-0.9.12 (0)
[I--] [ ] dev-libs/apr-util-1.2.8 (1)
|
On two machines.
Strange now revdep-rebuild wants to down grade KDE on the laptop:
Code: | Evaluating package order...
!!! Multiple versions within a single package slot have been
!!! pulled into the dependency graph:
('ebuild', '/', 'gnome-base/libgnomeui-2.16.1', 'merge') (no parents)
('ebuild', '/', 'gnome-base/libgnomeui-2.18.1', 'merge') pulled in by
('ebuild', '/', 'gnome-base/gnome-mount-0.6', 'merge')
done.
(/root/.revdep-rebuild.5_order)
All prepared. Starting rebuild...
emerge --oneshot -p =dev-libs/apr-util-0.9.12 =gnome-base/libbonoboui-2.16.0 =gnome-base/libgnomeui-2.16.1 =sys-devel/gcc-4.1.2 =kde-base/kdegraphics-3.5.5-r2
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild UD] kde-base/kdelibs-3.5.5-r10 [3.5.7-r2] USE="ssl%* -zeroconf%" LINGUAS="-he%"
[ebuild R ] dev-libs/apr-util-0.9.12
[ebuild R ] gnome-base/libbonoboui-2.16.0
[ebuild R ] gnome-base/libgnomeui-2.16.1
[ebuild R ] sys-devel/gcc-4.1.2
[ebuild UD] kde-base/kdebase-3.5.5-r4 [3.5.7-r3] USE="ssl%* -zeroconf%"
[ebuild R ] kde-base/kdegraphics-3.5.5-r2
Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild.
lapcat turtle # emerge -pv gettext XML-Parser
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] sys-devel/gettext-0.16.1-r1 USE="nls -doc -emacs -nocxx" 0 kB
[ebuild R ] dev-perl/XML-Parser-2.34-r1 0 kB
Total: 2 packages (2 reinstalls), Size of downloads: 0 kB
lapcat turtle # scanelf -pF '%F %n' | awk -v ORS=' ' '/libexpat.so.0/{print $1}'| xargs qfile -qvC | sort -u
gnome-base/libbonoboui-2.16.0
lapcat turtle #
|
Not sure what to do.
Is anyone still using emwrap.sh for stuff like this?[/code]
EDIT:
For those whom are interested a bug has been filed as to the procedural problem of an ebuild post install warning not giving the user the choice that Gentoo should offer. In this cast the choice is to have a broken system now or later. Please leave your comments and suggestions. _________________ Donate to Gentoo |
|
Back to top |
|
|
GODLiKE n00b
Joined: 11 Jan 2007 Posts: 62
|
Posted: Tue Aug 21, 2007 3:07 am Post subject: |
|
|
turtles wrote: | I am wandering my way through this and experiencing some issues with Code: | Calculating dependencies... done!
[ebuild R ] dev-libs/apr-util-1.2.8
|
It seems that revdep-rebuild just wants to keep rebuilding it.
I added a bug in bugzilla 189642 If you think this should have been a blocker add a comment to the bug. I will open a thread in user relations when the bug gets closed as a wont fix. |
I had the same problem last night. revdep-rebuild -X --library libexpat.so.0 would always re emerge apr-util but Apache would not start.
I fixed it by doing a plain revdep-rebuild. But it seems my server was in better conditions than your box =/. _________________ GERÓNIMOOOOOOOOOOOOOOOOOOOO!!! |
|
Back to top |
|
|
Carnildo Guru
Joined: 17 Jun 2004 Posts: 594
|
Posted: Tue Aug 21, 2007 4:11 am Post subject: |
|
|
datenwolf wrote: | I think symlinking libexpat.so.1.5.1 -> libexpat.so.0 should be safe for now. Expat is written in pure C, so the only ABI there is is the C ABI which hasn't changed for decades. This is unlike C++, where name mangling rules and the way templates are dealt with are changed oftenly.
AFAIK Expat-2 has been designed with API compatibility in mind (this is also written on the Expat homepage). Being a pure C library this means, that all functions whose prototype hasn't changed will be binary compatible.
So? What ABI change is there? Please give me an exact awnser like "functions are now not longer stdcall-ed but fastcall-ed" or "parameters for function xxx have changed" or similair. |
Odds are, it's a data structure with private data. Say you've got the following structure in expat 1:
Code: | struct _MYSTR
{
int useritem1;
int useritem2;
}; |
And in expat 2, it's defined as follows:
Code: | struct _MYSTR
{
int useritem1;
int useritem2;
char * internalitem1;
void * internalitem2;
}; |
From the user's perspective, the two functions are used identically. But passing a pointer to an expat 1 "_MYSTR" to an expat 2 function will result in the function reading or writing areas of memory it's not supposed to. Most of the time, this won't be a problem, but occasionally you'll generate hard-to-track bugs. |
|
Back to top |
|
|
stef Tux's lil' helper
Joined: 23 Jul 2003 Posts: 93
|
Posted: Tue Aug 21, 2007 9:32 am Post subject: |
|
|
@Carnildo:
so ... wouldn't just be keeping a copy of the old version of the library be the "correct" temporary solution (better than symlinking to the new) ... as in my post yesterday (see above)? |
|
Back to top |
|
|
VinzC Watchman
Joined: 17 Apr 2004 Posts: 5098 Location: Dark side of the mood
|
Posted: Tue Aug 21, 2007 12:16 pm Post subject: |
|
|
stef wrote: | @Carnildo:
so ... wouldn't just be keeping a copy of the old version of the library be the "correct" temporary solution (better than symlinking to the new) ... as in my post yesterday (see above)? |
Absolutely. Unless alignment is Q-Word based (assuming a pointer equals a WORD) the risk is segmentation faults. Given that many system applications link to expat... _________________ Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
Back to top |
|
|
turtles Veteran
Joined: 31 Dec 2004 Posts: 1658
|
Posted: Tue Aug 21, 2007 2:53 pm Post subject: |
|
|
I seem to have a "orphaned file, deep
dependency, binary package or specially evaluated library"
revdep-rebuild is now stuck in a endless loop just wanting to recomiple GCC all the time:
here is the end of last nights recompile of GCC, removing the temp files, me removing the temp files manualy just to be sure and it wanting to do it all again:
Code: | * GNU info directory index is up-to-date.
Build finished correctly. Removing temporary files...
You can re-run revdep-rebuild to verify that all libraries and binaries
are fixed. If some inconsistency remains, it can be orphaned file, deep
dependency, binary package or specially evaluated library.
|
Code: | lapcat turtle # rm /root/.revdep* |
Code: |
lapcat turtle # revdep-rebuild -p -X
Configuring search environment for revdep-rebuild
Checking reverse dependencies...
Packages containing binaries and libraries broken by a package update
will be emerged.
Collecting system binaries and libraries... done.
(/root/.revdep-rebuild.1_files)
Collecting complete LD_LIBRARY_PATH... done.
(/root/.revdep-rebuild.2_ldpath)
Checking dynamic linking consistency...
broken /usr/bin/bonobo-browser (requires libexpat.so.0)
broken /usr/bin/test-moniker (requires libexpat.so.0)
broken /usr/kde/3.5/lib/kde3/kfile_pdf.so (requires libexpat.so.0)
broken /usr/lib/bonobo-2.0/samples/bonobo-sample-controls-2 (requires libexpat.so.0)
broken /usr/libexec/gnome_segv2 (requires libexpat.so.0)
broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires /usr/lib/lib-gnu-java-awt-peer-gtk.la)
done.
(/root/.revdep-rebuild.3_rebuild)
Assigning files to packages...
/usr/bin/bonobo-browser -> gnome-base/libbonoboui
/usr/bin/test-moniker -> gnome-base/libbonoboui
/usr/kde/3.5/lib/kde3/kfile_pdf.so -> kde-base/kdegraphics
/usr/lib/bonobo-2.0/samples/bonobo-sample-controls-2 -> gnome-base/libbonoboui
/usr/libexec/gnome_segv2 -> gnome-base/libgnomeui
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la -> sys-devel/gcc
done.
(/root/.revdep-rebuild.4_packages_raw, /root/.revdep-rebuild.4_package_owners)
Cleaning list of packages to rebuild... done.
(/root/.revdep-rebuild.4_packages)
Assigning packages to ebuilds... done.
(/root/.revdep-rebuild.4_ebuilds)
Evaluating package order... done.
(/root/.revdep-rebuild.5_order)
All prepared. Starting rebuild...
emerge --oneshot -p =sys-devel/gcc-4.1.2
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] sys-devel/gcc-4.1.2
Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild.
|
How do we deal with this issue? _________________ Donate to Gentoo |
|
Back to top |
|
|
VinzC Watchman
Joined: 17 Apr 2004 Posts: 5098 Location: Dark side of the mood
|
Posted: Tue Aug 21, 2007 2:55 pm Post subject: |
|
|
What are your USE flags with GCC?
(EDIT: you probably USEd gcj, didn't you?) _________________ Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
Back to top |
|
|
isolationism Tux's lil' helper
Joined: 01 Nov 2004 Posts: 127
|
Posted: Tue Aug 21, 2007 6:28 pm Post subject: |
|
|
drumgod wrote: | "equery list apr-util" will most likely show you that you have apr-util-0.9.12-r1 installed as well. "revdep-rebuild -X" finds the dependency in the older version then re-installs the newer version because of the -X flag... |
This is what helped me get Subversion up and running again; thank you.
To clarify: I've been running revdep-rebuild -X which is building the new versions of the apr-util and apr packages -- but I have two of each installed, so the -X flag was only rebuilding the newer ones. What I did was re-emerge these all explicitly:
Code: | emerge =dev-libs/apr-0.9.12 =dev-libs/apr-1.2.8 =dev-libs/apr-util-0.9.12-r1 =dev-libs/apr-util-1.2.8 |
... followed by re-emerging Subversion:
... And that did it. Thank you. drumgod, for pointing out my error. |
|
Back to top |
|
|
turtles Veteran
Joined: 31 Dec 2004 Posts: 1658
|
Posted: Tue Aug 21, 2007 6:30 pm Post subject: |
|
|
It looks like gcj is enabled. Code: | Calculating dependencies... done!
[ebuild R ] sys-devel/gcc-4.1.2 USE="fortran gcj gtk mudflap nls (-altivec) -bootstrap -build -d -doc (-hardened) -ip28 -ip32r10k (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc -test -vanilla" 0 kB |
dep -u gcc
gives me Code: | -gcj* : Enable building with gcj (The GNU Compiler for the Javatm Programming Language)
| among other things.
I forgot the last time I updated I had an persistant revde-rebuild issue here with sys-devel/gcc.
I fixed it with a Code: | ln -sf /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcj.la /usr/lib/libgcj.la
| I also forgot I will have to re do this every time I emerge gcc.
I am guessing Code: | emerge -1 gnome-base/libbonoboui kde-base/kdegraphics gnome-base/libgnomeui | Will take care of the requires libexpat.so.0 issues. _________________ Donate to Gentoo |
|
Back to top |
|
|
Mocho n00b
Joined: 17 Jun 2006 Posts: 20 Location: Magdeburg, Germany
|
Posted: Tue Aug 21, 2007 9:32 pm Post subject: Pango problem |
|
|
Hi guys, thanks for all the hints. Unfortunately, they do not work for me as "emerge pango" fails although it is supposed to be one of the first steps in resolving the problem. When failing it complains about the missing libexpat.so.0-file. I already re-emerged packages like libXft, fontconfig, cairo and lots of other stuff right before w/o success. I'd be really glad if you could give me some "boost" concerning this problem.
Last but not least here's the bitter end of an "emerge pango":
Code: | creating pango-tibetan-fc.la
(cd .libs && rm -f pango-tibetan-fc.la && ln -s ../pango-tibetan-fc.la pango-tibetan-fc.la)
make[3]: Leaving directory `/var/tmp/portage/x11-libs/pango-1.16.4/work/pango-1.16.4/modules/tibetan'
make[3]: Entering directory `/var/tmp/portage/x11-libs/pango-1.16.4/work/pango-1.16.4/modules'
Writing a pango.modules file to use with tests/examples.
/var/tmp/portage/x11-libs/pango-1.16.4/work/pango-1.16.4/pango/.libs/lt-pango-querymodules: error while loading shared libraries: libexpat.so.0: cannot open shared object file: No such file or directory
make[3]: *** [pango.modules] Fehler 127
make[3]: Leaving directory `/var/tmp/portage/x11-libs/pango-1.16.4/work/pango-1.16.4/modules'
make[2]: *** [all-recursive] Fehler 1
make[2]: Leaving directory `/var/tmp/portage/x11-libs/pango-1.16.4/work/pango-1.16.4/modules'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/var/tmp/portage/x11-libs/pango-1.16.4/work/pango-1.16.4'
make: *** [all] Fehler 2
!!! ERROR: x11-libs/pango-1.16.4 failed.
Call stack:
ebuild.sh, line 1638: Called dyn_compile
ebuild.sh, line 985: Called qa_call 'src_compile'
ebuild.sh, line 44: Called src_compile
ebuild.sh, line 1328: Called gnome2_src_compile
gnome2.eclass, line 71: Called die
!!! compile failure
|
|
|
Back to top |
|
|
VinzC Watchman
Joined: 17 Apr 2004 Posts: 5098 Location: Dark side of the mood
|
Posted: Tue Aug 21, 2007 9:50 pm Post subject: |
|
|
turtles wrote: | It looks like gcj is enabled. |
Code: | Calculating dependencies... done!
[ebuild R ] sys-devel/gcc-4.1.2 USE="fortran gcj gtk mudflap nls (-altivec) -bootstrap -build -d -doc (-hardened) -ip28 -ip32r10k (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc -test -vanilla" 0 kB |
I only have nls and mudflap on my system. Are you sure all these flags are required by your side? If no then disabling them (i.e. mostly gtk and gcj) will decrease dependencies, which is critical for something like GCC on Gentoo... _________________ Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
Back to top |
|
|
jrolandwright n00b
Joined: 18 Jan 2006 Posts: 3
|
Posted: Tue Aug 21, 2007 9:53 pm Post subject: Re: I'm usually a Gentoo Fan, BUT.. |
|
|
Voltago wrote: | Sometimes upgrades cause ABI breakages, there's no way around that short of hanging on to the old version forever. If you use a source distro, you have to keep that in mind. |
So, in other words, if you use Gentoo, you have to keep in mind that sometimes routine upgrades using officially supported package management will break your system. It won't tell you why or how. You won't be warned. It'll just stop working and that's just the way it is.
An unstable or officially breakage-prone package management system is patently unacceptable for regular use and it has nothing to do with Gentoo being a source-based distro. It has to do with quality control and, more negligently, quality assurance. If this were my toy box, I could take it in stride... but Gentoo is my primary desktop and my server o/s. [/i]I can't have a primary desktop with it's own custom "blue screen of death" in the form of a libexpat error.
I've learned a lot using Gentoo, but I'm afraid its time has come and gone. |
|
Back to top |
|
|
VinzC Watchman
Joined: 17 Apr 2004 Posts: 5098 Location: Dark side of the mood
|
Posted: Tue Aug 21, 2007 10:00 pm Post subject: Re: Pango problem |
|
|
Mocho wrote: | Hi guys, thanks for all the hints. Unfortunately, they do not work for me as "emerge pango" fails although it is supposed to be one of the first steps in resolving the problem. When failing it complains about the missing libexpat.so.0-file. I already re-emerged packages like libXft, fontconfig, cairo and lots of other stuff right before w/o success. I'd be really glad if you could give me some "boost" concerning this problem.
[...] |
On my system, here's what expat is being depended on:
equery -q d expat: | dev-lang/python-2.3.5-r3 (!build? dev-libs/expat)
dev-lang/python-2.4.4-r4 (!build? dev-libs/expat)
dev-libs/apr-util-0.9.12-r1 (dev-libs/expat)
dev-perl/XML-Generator-1.0 (dev-libs/expat)
dev-perl/XML-Parser-2.34-r1 (>=dev-libs/expat-1.95.1-r1)
dev-python/pyxml-0.8.4 (>=dev-libs/expat-1.95.6)
kde-base/kdenetwork-3.5.7 (jingle? dev-libs/expat)
media-libs/fontconfig-2.4.2 (!xml? >=dev-libs/expat-1.95.3)
media-libs/libofa-0.9.3 (dev-libs/expat)
media-libs/mesa-6.5.2-r1 (dev-libs/expat)
media-libs/musicbrainz-2.1.4 (dev-libs/expat)
media-libs/tunepimp-0.5.3 (dev-libs/expat)
sys-apps/dbus-1.0.2-r2 (>=dev-libs/expat-1.95.8)
sys-apps/hal-0.5.9-r1 (>=dev-libs/expat-1.95.8)
sys-devel/gettext-0.16.1 (dev-libs/expat)
www-client/mozilla-firefox-2.0.0.6 (dev-libs/expat)
www-servers/apache-2.0.58-r2 (dev-libs/expat) |
And here are runtime dependencies of pango:
Code: | x11-libs/libXrender
x11-libs/libX11
x11-libs/libXft
>=dev-libs/glib-2.12
>=media-libs/fontconfig-1.0.1
>=media-libs/freetype-2
>=x11-libs/cairo-1.2.6 |
Did you try recompiling glib, gettext, apr-utils, hal, dbus and python (don't remember the exact order though)? _________________ Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
Back to top |
|
|
datenwolf n00b
Joined: 01 Sep 2003 Posts: 55
|
Posted: Tue Aug 21, 2007 11:01 pm Post subject: |
|
|
I still want to know: What ABI changes?!?!?
Expat is a goddam pure C library, there's nothing in the ABI that could change. The C ABI is dead simple: Push parameters on the stack, then call the function, when the function returns, pop parameters off the stack to clean up. There's no fancy name mangling like in C++ and no memory management involved. And Expat-2 only introduced new functions and cleaned up things internally. The external interface didn't change.
So why not simply make this link by default. In this case it won't break things. |
|
Back to top |
|
|
Mocho n00b
Joined: 17 Jun 2006 Posts: 20 Location: Magdeburg, Germany
|
Posted: Tue Aug 21, 2007 11:10 pm Post subject: |
|
|
Hi VinzC, thank you very much for your fast answer. I compiled the packages you suggested but still to no avail Pango just won't compile. What else can I do? |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|