faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Oh no...
by aleXXX on Wednesday 14/Sep/2005, @06:30
|
Well, I tried to work with autotools and tried to read the documentation. I didn't have success. You need to learn:
-m4
-libtool
-autoconf
-automake
These are just too many things to keep them all in your head if you use them only from time to time.
While I myself prefer cmake over scons, scons will definitely an improvement over autotools.
Alex |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Oh no...
by ac on Wednesday 14/Sep/2005, @06:58
|
But these tools m4, libtool, autoconf, automake are existing for how many years now ? You can ask basicly everyone to help you with it, you can even go to the next chinese fish store to ask some linux guru to help you while you probably won't find that many people helping you with Scons problems. But then again, Scons isn't really my problem. Python is (as if I haven't said this two dozen times now).
|
[
Reply To This | View ]
|
Re: Oh no...
by The Badger on Wednesday 14/Sep/2005, @09:27
|
"But these tools m4, libtool, autoconf, automake are existing for how many years now ?"
For so long that we're all born with inate knowledge of them?
"You can ask basicly everyone to help you with it, you can even go to the next chinese fish store to ask some linux guru to help you"
Dream on! Makefile and autotools gurus may be able to help you, but they're nowhere near as common as you make out. Even if the Internet is littered with autotools files, as you suggest elsewhere, that doesn't necessarily make troubleshooting any easier, as anyone with any experience of TeX authoring will tell you.
"while you probably won't find that many people helping you with Scons problems."
Sure, specific SCons experience is likely to be limited, but at least there's a chance that people will either get the language or get up to speed with it, rather than getting bogged down with the usual horseplay that shell-inspired toolsets entail.
"But then again, Scons isn't really my problem. Python is (as if I haven't said this two dozen times now)."
If only to contradict yourself in two dozen other places. But to distill this objection to Python down, it would appear that you see the installation of a tool you don't use as "wasteful" - in which case I imagine that you roll your own minimalistic Linux distribution in order to avoid all the other wasteful stuff that gets installed. Or don't tell me: you've said all this but actually run Fedora Core?!
|
[
Reply To This | View ]
|
Re: Oh no...
by Morty on Wednesday 14/Sep/2005, @17:10
|
>You can ask basicly everyone to help you with it,
I'll take your word for it. I encountered a small case a few days ago, can you please explain it to me. Why does it behave this way? I had a build error in the kdeaddons package when building noatun-plugins/blurscope. For some reason it decided to try linking to KDE files(libkdeprint,libkparts etc) in /usr rather than where KDEDIR is(/opt). I have some old KDE binaries in /usr as a backup solution when SVN builds to /opt fails, but no -devel RPMS so it does not find any .so files to link with there. Making one small change to the Makefile.am made everything build correctly. So please explain to me why these two lines works differently?
"noatunblurscope_la_LDFLAGS = $(all_libraries) -module -avoid-version -n o-undefined `$(SDL_CONFIG) --libs`"
"noatunblurscope_la_LDFLAGS = -module -avoid-version -n o-undefined `$(SDL_CONFIG) --libs` $(all_libraries)"
Why does one make it link against /usr and the other against /opt?
|
[
Reply To This | View ]
|
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.
|
[
Reply To This | View ]
|
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 )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
