faq  flatforty  contribute  subscribe  configure  search  rdf  main  parent  thread	Re: Oh no... by ac on Thursday 15/Sep/2005, @01:06 If I understand your problem correctly which I assume I do, then this is clearly the old known precedence problem (where to search first). But sadly it's not just libtool or gcc alone. They search in the default paths for libraries first. So if you have older libraries sitting in /usr and have the new ones compiled and installed in /opt/kde then you can be sure that libtool and gcc seeks for libraries in /usr first rather than in /opt/kde. Something you can not even solve with LD_LIBRARY_PATH. The correct solution would be to remove the old libraries in /usr anyways to avoid the problems. I encountered these issues some years ago when maintaining my own well known buildscript for another desktop environment. This is no Makefile issue, nor is it a configure or autotools issue. It's an issue of precedence of where the compiler and linker or libtools is searching first. IIRC JHBuild on freedesktop.org provides a patch for libtool to search in ${prefixdir}/lib first. But then these bugs are solvable it's just a matter of time that someone writes a bugreport and sents it to the maintainers so they can add it. Nothing wrong about that.	Related Links  ·   Articles on Developer  ·   Also by ac  ·   Contact author Thread Threshold: 10 comments 20 comments 30 comments 40 comments 50 comments 60 comments 70 comments 80 comments 90 comments 100 comments 110 comments 120 comments 130 comments 140 comments 150 comments 160 comments 170 comments 180 comments 190 comments 200 comments 300 comments 400 comments 500 comments 1000 comments
	The Fine Print: The following comments are owned by whomever posted them. ( Reply ) Re: Oh no... by Roberto Alsina on Thursday 15/Sep/2005, @02:20 If the problem is old and known and there is a patch around, why is it necessary to write a bug report and send it to the maintainers? [ Reply To This | View ] Re: Oh no... by ac on Thursday 15/Sep/2005, @02:24 The patch comes bundled with the jhbuild package, I don't know why it wasn't forwarded and I never bothered to ask either. Could be that it was sent to them and rejected, who knows. [ Reply To This | View ] Re: Oh no... by Christian Loose on Thursday 15/Sep/2005, @03:20 > This is no Makefile issue, nor is it a configure or autotools issue. It's an issue of precedence of where the compiler and linker or libtools is searching first. That doesn't answer the question, why the change fixed the problem. Why does putting $(all_libraries) at last posititon change the precedence? [ Reply To This | View ] Re: Oh no... by ac on Thursday 15/Sep/2005, @03:47 I can not answer this without knowing the whole problem case. This also requires to know what system he uses, what's installed on it, what he really did, etc. Giving an direct answer to this over dot.kde.org without knowing all facts would be far to unserious. But all I know so far is that this is not an autotools issue. It's of course clear that if I force the precedence to be differently that stuff may work as in this case. [ Reply To This | View ] Re: Oh no... by Morty on Thursday 15/Sep/2005, @08:52 >The correct solution would be to remove the old libraries in /usr anyways to avoid the problems. No it's not the correct solution, for several reasons. First the ability to have several versions of KDE installed is a feature, and I don't think removing the stable version for unstable/svn version would be particularly popular by some of the users on this box(me included:-). >This is no Makefile issue, nor is it a configure or autotools issue. It's an issue of precedence of where the compiler and linker or libtools is searching first. How come simple changes to Makefile.am make it work or not, without any other changes anywhere. If it had been that simple the rest of the package would also have had failed building, and not only the one lone directory. As $(all_libraries) are positioned both places in the rest of the package. And the same can be said of the 10 other KDE source packages which builds correctly in the same environment, not having any precedence problems. Personally I think such unpredictable behavior in the build systems clearly confirms it has major issues. [ Reply To This | View ] The Fine Print: The previous comments are owned by whomever posted them. ( Reply )

		"Spare time? What's that?" -- Dirk Mueller
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.

[ home | post article | flat forty | subscribe | search | rdf ]