I don't know where to start but apparently cmake, or something related to cmake with respect to Trinity, or pkgconfig, is broken on my Slackware 13.1 build environment.
Tim helped me with some testing. We know that something is not right when trying to build Trinity on Slackware, but we have to find the root cause. Tim believes the built-in pkgconfig system in my build environment is not working correctly.
I have not experienced any build issues with many other cmake packages not related to Trinity. I have been building my own packages for many years. I would have noticed something awry with other packages and not just Trinity packages. Therefore I believe the problem is limited to my build environment for Trinity.
The problems are provided in bug report 581, but narrow to this:
1) cmake will not populate the internal TQT_INCLUDE_DIRS variable. Although the problematic package reported in bug report 581 is tdelibs, I have verified this to be true with arts and tdebase too. Oddly, both of those packages build without that internal variable being set. Regardless, the problem seems to be fundamental that TQT_INCLUDE_DIRS never gets populated. Because of this failure to populate that internal cmake variable, the tdelibs build fails almost immediately with this error:
cc1: error: tqt.h: No such file or directory
Of course, tqt.h does indeed exist in my build environment. Nobody else has reported this failure.
2) The second problem is tdelibs will not build unless a sym link exists:
cd /usr/include/tqt; ln -s ${QTDIR}/include/qglobal.h qglobal.h
At least one other Slackware user reported this same sym link requirement: http://trinity-devel.pearsoncomputing.net/?0::3307
According to Tim, the sym link is not required by anybody else.
Oddly, arts and tdebase will build without the TQT_INCLUDE_DIRS internal variable and the sym link. tdelibs and tdevelop both fail to build without these requirements being met.
In my tdelibs build script I wrote a small test that executes just after the cmake configure and before make. All I did in my snippet was look for a value in TQT_INCLUDE_DIRS and when empty, grab the value from TQT_INCLUDEDIR and populate TQT_INCLUDE_DIRS with that value.
That produced some nominal success. Instead of the usual cc1 message about tqt.h not existing, I received an error message about not finding qglobal.h. I inserted a aforementioned sym link and then the tdelib package built.
So even if I discover how to get the TQT_INCLUDE_DIRS internal variable to populate automatically, I still need to figure out why this sym link is needed when nobody else does.
I'm using cmake 2.8.4 on Slackware 13.1, although the stock Slackware 13.1 came with 2.8.1.
I have tested this with and without Qt4 being installed, so the problem is not crossing paths with Qt4.
I'm open to the idea that I'm not correctly setting environment variables, or that I am making a common mistake or presumption throughout my build scripts. I am not embarrassed if this turns out to be a PEBKAC issue. :)
I appreciate any help. There is an interest in Trinity in the Slackware community and my web site gets quite a few hits every day at my KDE3 and Trinity pages. I'd like to get these problems resolved because others in the Slackware community look to me as a pivot point to build and use KDE3 and Trinity.
I know next to nothing about cmake or pkgconfig. I just use them. :) So please start with the basics when trying to help. Don't assume I know better --- I probably don't, although I learn quickly. :)
Thanks much!
Darrell
<snip>
- The second problem is tdelibs will not build unless a sym link exists:
cd /usr/include/tqt; ln -s ${QTDIR}/include/qglobal.h qglobal.h
At least one other Slackware user reported this same sym link requirement: http://trinity-devel.pearsoncomputing.net/?0::3307
According to Tim, the sym link is not required by anybody else.
<snip>
The symlink problem is also related to the CMake problem. Once the include directory variable is correctly generated this problem will also go away (you are currently missing the Qt3/TQt3 include directory when copying the existing include variable to the new include variable).
It is interesting that you have not noticed any problems with other CMake builds. This would seem to point to TDE at a minimum triggering a bug in CMake, and in the worst case something very obscure is wrong. Serghei probably knows much more about CMake than I do, so I am waiting for his response.
Tim
I don't know where to start but apparently cmake, or something related to cmake with respect to Trinity, or pkgconfig, is broken on my Slackware 13.1 build environment. ...
Looks like "airing out" in public has already helped some. :)
I just discovered that when I manually populate the internal variable TQT_INCLUDE_DIRS=/usr/include/tqt;${QTDIR}/include between the cmake configure and make, I no longer need the sym link.
Progress? :)
The problem now seems narrowed to one point: to discover why the TQT_INCLUDE_DIRS internal variable does not automatically populate.
Question: what is the correct value for that internal variable?
Darrell
I don't know where to start but apparently cmake, or something related to cmake with respect to Trinity, or pkgconfig, is broken on my Slackware 13.1 build environment. ...
Looks like "airing out" in public has already helped some. :)
I just discovered that when I manually populate the internal variable TQT_INCLUDE_DIRS=/usr/include/tqt;${QTDIR}/include between the cmake configure and make, I no longer need the sym link.
Progress? :)
The problem now seems narrowed to one point: to discover why the TQT_INCLUDE_DIRS internal variable does not automatically populate.
Question: what is the correct value for that internal variable?
This will be determined by the output of the pkg-config command pkg-config --cflags-only-I tqt
For example, on my system that command spits out: -I/usr/include/qt3 -I/usr/include/tqt
My CMakeCache.txt file for tdelibs is attached.
Tim
Question: what is the correct value for that internal
variable?
This will be determined by the output of the pkg-config command pkg-config --cflags-only-I tqt
For example, on my system that command spits out: -I/usr/include/qt3 -I/usr/include/tqt
My CMakeCache.txt file for tdelibs is attached.
Thanks. At least I have a workaround with my script function to fix on-the-fly. Seems to be working nicely, but still bothers me.
I notice in your qt3 build options you use the following:
-headerdir "/usr/include/qt3"
I let qt3 install the headers to its own default location at $QTDIR/include. Do you think that makes a difference with pkg-config not working because the headers are not in the standard /usr/include location?
I submitted a bug report about qt3 installing its pkg-config file in an odd location (bug report 796). Although I ceate a sym link, could that be confusing pkg-config with extracting information?
Do you need that sym link on your system? If not, then how do you get your qt3 qt-mt.pc installed to /usr/lib/pkgconfig/? Or do you add that odd location to your system's $PKG_CONFIG_PATH environment variable? I'm adding that odd location to my $PKG_CONFIG_PATH path.
I'm just looking for any anomaly. Grasping at the wind...
Darrell
Question: what is the correct value for that internal
variable?
This will be determined by the output of the pkg-config command pkg-config --cflags-only-I tqt
For example, on my system that command spits out: -I/usr/include/qt3 -I/usr/include/tqt
My CMakeCache.txt file for tdelibs is attached.
Thanks. At least I have a workaround with my script function to fix on-the-fly. Seems to be working nicely, but still bothers me.
I notice in your qt3 build options you use the following:
-headerdir "/usr/include/qt3"
I let qt3 install the headers to its own default location at $QTDIR/include. Do you think that makes a difference with pkg-config not working because the headers are not in the standard /usr/include location?
No, it won't make any difference. That's why I had you manually check the pkg-config output, which looked perfectly fine.
I submitted a bug report about qt3 installing its pkg-config file in an odd location (bug report 796). Although I ceate a sym link, could that be confusing pkg-config with extracting information?
No, same as above it won't make any difference.
Do you need that sym link on your system? If not, then how do you get your qt3 qt-mt.pc installed to /usr/lib/pkgconfig/? Or do you add that odd location to your system's $PKG_CONFIG_PATH environment variable? I'm adding that odd location to my $PKG_CONFIG_PATH path.
Debian moves the file around after build/install and before packaging IIRC.
The only other thing I can think of at all is that you could theoretically have an old tqt.pc (or similar) file floating around in an obscure directory. I would search the entire system for such a file, just in case an old one without the include directories is being picked up by CMake and pkg-config together.
Assuming you don't find a stale tqt.pc file there are a few options open to you: 1.) Manually extract the pkg-config information and patch the build on-the-fly as you are doing now. Just make sure to add a Nasty Hack Warning Message to your build scripts stating that this is only to work around a puzzling problem in CMake on Slackware for now. ;-) 2.) Post on the CMake mailing list with all the debugging information you gave me, including your CMake version, CMakeCache.txt file, and tqt.pc file. Ask them why their built-in pkg_search_module() function is populating everything EXCEPT <XPREFIX>_INCLUDE_DIRS. 3.) Upgrade your CMake version (this is a long shot, as the problem could be in a dependent library for all I know) 4.) Try to replicate the problem on a Debian/Ubuntu system. If you can do that, and give me detailed instructions for replication, I can debug it myself and hack around whatever is going wrong
Until someone else can replicate this problem, I am going to mark Bug 581 as RESOLVED NOTOURPROBLEM.
Sorry I can't be much more help here!
Tim
The only other thing I can think of at all is that you could theoretically have an old tqt.pc (or similar) file floating around in an obscure directory. I would search the entire system for such a file, just in case an old one without the include directories is being picked up by CMake and pkg-config together.
Only one tqt.pc found.
ld.so.conf was messed up, however, probably from so much experimenting.
Assuming you don't find a stale tqt.pc file there are a few options open to you: 1.) Manually extract the pkg-config information and patch the build on-the-fly as you are doing now. Just make sure to add a Nasty Hack Warning Message to your build scripts stating that this is only to work around a puzzling problem in CMake on Slackware for now.
Well here is an interesting turn of events. I added the following to my ugly script function hack:
pkg-config --cflags-only-I tqt
The command returns no results.
When directly in a terminal the command returns the expected -I/usr/lib/qt3/include -I/usr/include/tqt.
So perhaps the problem is right there. For whatever reason pkg-config is not running from within scripts. Or is dumping the results to the bit bucket.
Anybody have ideas why? I haven't yet found anything on the web.
Darrell
The only other thing I can think of at all is that you could theoretically have an old tqt.pc (or similar) file floating around in an obscure directory. I would search the entire system for such a file, just in case an old one without the include directories is being picked up by CMake and pkg-config together.
Only one tqt.pc found.
ld.so.conf was messed up, however, probably from so much experimenting.
Assuming you don't find a stale tqt.pc file there are a few options open to you: 1.) Manually extract the pkg-config information and patch the build on-the-fly as you are doing now. Just make sure to add a Nasty Hack Warning Message to your build scripts stating that this is only to work around a puzzling problem in CMake on Slackware for now.
Well here is an interesting turn of events. I added the following to my ugly script function hack:
pkg-config --cflags-only-I tqt
The command returns no results.
When directly in a terminal the command returns the expected -I/usr/lib/qt3/include -I/usr/include/tqt.
So perhaps the problem is right there. For whatever reason pkg-config is not running from within scripts. Or is dumping the results to the bit bucket.
<snip>
Yes, that is the problem right there!
I would dump the environemnt (via the 'env' command) in your terminal and from within in the build script to see what is different. Usually this kind of problem is caused by an incorrectly set environment variable.
Tim
Well here is an interesting turn of events. I added
the following to my
ugly script function hack:
pkg-config --cflags-only-I tqt
The command returns no results.
When directly in a terminal the command returns the
expected
-I/usr/lib/qt3/include -I/usr/include/tqt.
So perhaps the problem is right there. For whatever
reason pkg-config is
not running from within scripts. Or is dumping the
results to the bit
bucket.
<snip>
Yes, that is the problem right there!
I would dump the environemnt (via the 'env' command) in your terminal and from within in the build script to see what is different. Usually this kind of problem is caused by an incorrectly set environment variable.
Beat you to the punch. :)
I might not be a crack developer, but I can troubleshoot with some of the best. ;)
You might not believe the cause of this entire problem. Are you ready for this?
Setting the $CPLUS_INCLUDE_PATH in the build environment prevents pkg-config from running properly. The moment I commented out that export command in my master script, the TQT_INCLUDE_DIRS internal variable began populating automatically.
Okay, for the record: Woo-hoo!
Now, why does the $CPLUS_INCLUDE_PATH environment variable, or the contents thereof, affect how pkg-config runs?
Second, should I be setting that environment variable?
Here is my normal setting for that variable:
CPLUS_INCLUDE_PATH: /usr/include/tqt:/usr/lib/qt3/include:/usr/include
Those locations are legitimate.
I set $CMAKE_INCLUDE_PATH to the same, but I did not start setting that variable until recently. That is, this TQT_INCLUDE_DIRS problem existed long before I started setting the $CMAKE_INCLUDE_PATH variable. The $CPLUS_INCLUDE_PATH is the cause.
Ideas?
Darrell
On Thursday 19 January 2012 04:32:05 pm Darrell Anderson wrote:
Well here is an interesting turn of events. I added
the following to my
ugly script function hack:
pkg-config --cflags-only-I tqt
The command returns no results.
When directly in a terminal the command returns the
expected
-I/usr/lib/qt3/include -I/usr/include/tqt.
So perhaps the problem is right there. For whatever
reason pkg-config is
not running from within scripts. Or is dumping the
results to the bit
bucket.
<snip>
Yes, that is the problem right there!
I would dump the environemnt (via the 'env' command) in your terminal and from within in the build script to see what is different. Usually this kind of problem is caused by an incorrectly set environment variable.
Beat you to the punch. :)
I might not be a crack developer, but I can troubleshoot with some of the best. ;)
You might not believe the cause of this entire problem. Are you ready for this?
Setting the $CPLUS_INCLUDE_PATH in the build environment prevents pkg-config from running properly. The moment I commented out that export command in my master script, the TQT_INCLUDE_DIRS internal variable began populating automatically.
Okay, for the record: Woo-hoo!
Now, why does the $CPLUS_INCLUDE_PATH environment variable, or the contents thereof, affect how pkg-config runs?
Second, should I be setting that environment variable?
Here is my normal setting for that variable:
CPLUS_INCLUDE_PATH: /usr/include/tqt:/usr/lib/qt3/include:/usr/include
Those locations are legitimate.
I set $CMAKE_INCLUDE_PATH to the same, but I did not start setting that variable until recently. That is, this TQT_INCLUDE_DIRS problem existed long before I started setting the $CMAKE_INCLUDE_PATH variable. The $CPLUS_INCLUDE_PATH is the cause.
Ideas?
Darrell
FYI
<warning a bit of a rant follows>
(and you can tell me to piss off if you want)
I try to keep to FHS as much as possible so I don't incur this type of wrath from pkg-config and the gnu tool chain. To say nothing of actually ruining the beast when you've finished getting it to build.
This why I put TDE into /usr so the build environment doesn't cause me gas and bloating... and I know it will run when I get the beast installed.
I put qt3 into /usr/local so I avoid problems with qt4.
/usr and /usr/local are usally configured on most distributions linker paths and it's in the PATH so then I don't as the packager have to jump through hoops etc.
You folks can do what ever you wish but for me I am sticking to FHS and puting this thing into /usr/local.
I don't know where all this /opt and company came from but.....
When I finally get to rebuilding TDE I will put the whole thing into /usr/local. It will not interfere with KDE4 and QT4 and as an added benifit I don't have to mess with PATH nor the linker path etc. It just works. ;) May I suggest you think about changing /opt or where ever you installed this beast and place your work into /usr/local as well.
/usr/local is clean and has nothing else installed there. So I have the play ground to myself.
I think most distros don't put things there by default.
/<warning a bit of a rant follows>
Baho Utot wrote:
I try to keep to FHS as much as possible so I don't incur this type of wrath from pkg-config and the gnu tool chain. To say nothing of actually ruining the beast when you've finished getting it to build.
This why I put TDE into /usr so the build environment doesn't cause me gas and bloating... and I know it will run when I get the beast installed.
And what happens if you are using that version of Trinity in /usr and want to test the latest. You write over your working executable or library with one that may or may not work with the existing packages?
I put qt3 into /usr/local so I avoid problems with qt4.
That tells me you don't know anything about qt3 or qt4. There are no name conflicts with the two libraries. The only issue is the PATH for a few development executables like qmake and moc. If you are building for qt3, you set the PATH one way. For qt4, another. It can be easily scripted.
/usr and /usr/local are usally configured on most distributions linker paths and it's in the PATH so then I don't as the packager have to jump through hoops etc.
Configured for what? /usr/local/{bin,lib} are empty by default.
You folks can do what ever you wish but for me I am sticking to FHS and puting this thing into /usr/local.
Have you *read* the FHS? What does it say about /opt?
Let me read it for you: "/opt is reserved for the installation of add-on application software packages. A package to be installed in /opt must locate its static files in a separate /opt/<package> or /opt/<provider> directory tree, where <package> is a name that describes the software package and <provider> is the provider's LANANA registered name."
I don't know where all this /opt and company came from but.....
You are right. You don't know.
When I finally get to rebuilding TDE I will put the whole thing into /usr/local. It will not interfere with KDE4 and QT4 and as an added benifit I don't have to mess with PATH nor the linker path etc. It just works. ;)
Your system your rules.
May I suggest you think about changing /opt or where ever you installed this beast and place your work into /usr/local as well.
You may suggest, but it is a poor suggestion. How would you have a trinity-3.5.13, trinity-3.5.14, and a trinity-dev on the same system?
Do this in /usr/local:
lrwxrwxrwx 1 root root 9 Dec 14 21:55 qt -> qt-3.3.8d drwxr-xr-x 11 root root 4096 Dec 1 2005 qt-3.3.5 drwxr-xr-x 11 root root 4096 Nov 3 2007 qt-3.3.8 drwxr-xr-x 11 root root 4096 Apr 22 2007 qt-3.3.8-nomysql drwxr-xr-x 11 root root 4096 Dec 14 21:55 qt-3.3.8d drwxr-xr-x 12 root root 4096 Mar 5 2008 qt-4.3.4 drwxr-xr-x 13 root root 4096 May 21 2009 qt-4.5.0 drwxr-xr-x 13 root root 4096 Aug 18 2009 qt-4.5.2 drwxr-xr-x 14 root root 4096 Oct 12 2010 qt-4.7.0 drwxr-xr-x 14 root root 4096 Jan 10 15:04 qt-4.8.0
lrwxrwxrwx 1 root root 9 Aug 18 2009 kde -> kde-3.5.10 drwxr-xr-x 7 root root 4096 Dec 12 2006 kde-3.5.2 drwxr-xr-x 7 root root 4096 Aug 18 2009 kde-3.5.10 drwxr-xr-x 7 root root 4096 Dec 19 22:18 trinity -> trinity-3.5.13 drwxr-xr-x 7 root root 4096 Dec 19 12:34 trinity-dev drwxr-xr-x 5 root root 4096 Dec 18 21:06 trinity-3.5.13
-- Bruce
On Thursday 19 January 2012 05:55:21 pm Bruce Dubbs wrote:
Baho Utot wrote:
I try to keep to FHS as much as possible so I don't incur this type of wrath from pkg-config and the gnu tool chain. To say nothing of actually ruining the beast when you've finished getting it to build.
This why I put TDE into /usr so the build environment doesn't cause me gas and bloating... and I know it will run when I get the beast installed.
And what happens if you are using that version of Trinity in /usr and want to test the latest. You write over your working executable or library with one that may or may not work with the existing packages?
I have a plan.
The package manager (pacman) I use handles that with ease and does this without any major trouble. If you really want a challenge upgrade glibc in place across major version not minor version, with pacman it's easy. Rebuilding as LFS does it is one way but pacman can handle it on a running machine properly. Yes I know you need to rebuild everything, that easy too with pacman. Bump release numbers and do a rebuild on the packge repo and you're good to go. In fact that is what I am currently doing with LFS, building it with pacman. Then I don't need to rebuild the system only what is changed. Any way I digress.....
Well for example I can remove 3.5.13 that is installed into /usr. Then install 3.5.14 into /usr. If it doesn't work I can down grade By simply pacman -Rsn;pacman -S tde-3.5.13 and all is well. Or I can do as you have see way below.
Or I can pacman -Syu tde which would upgrade TDE in place to 3.5.14 and again if it is broken I can do pacman -S tde-3.5.13 and it will down grade all the packages to 3.5.13 and all is well and I am back where I started. The only thing that is gone is the time.
I put qt3 into /usr/local so I avoid problems with qt4.
That tells me you don't know anything about qt3 or qt4. There are no name conflicts with the two libraries. The only issue is the PATH for a few development executables like qmake and moc. If you are building for qt3, you set the PATH one way. For qt4, another. It can be easily scripted.
Yes but I don't need to do that. I only have one app that needs qt4. I'll address it when and if I need more apps that need qt4 but for now one is all I need.
I use to have qt3 and qt4 installed into /usr. That is the way it was when I first built TDE. I changed it so I would have to muck around with the paths. The way it is now I just build and don't have to mess with the paths. Also since tde is the only thing that I have that uses qt3 putting it into /usr/local means that tde and qt3 is in one place. Empty /usr/local and TDE and company is gone. Not that I would do that, again pacman -Rsn tde does that automatically.
/usr and /usr/local are usally configured on most distributions linker paths and it's in the PATH so then I don't as the packager have to jump through hoops etc.
Configured for what? /usr/local/{bin,lib} are empty by default.
Yes that is why I call it my play ground echo $PATH /usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/core_perl pkg-config is configured to look into /usr/lib and /usr/local/lib/config ld is also configured to look at /lib and /usr/local/lib So I am good to go/play with tde. Minimum fuss. If I really make a mess I can just empty /usr/local.
You folks can do what ever you wish but for me I am sticking to FHS and puting this thing into /usr/local.
Have you *read* the FHS? What does it say about /opt?
Yes I have read that. In fact I have a pdf document.
Let me read it for you: "/opt is reserved for the installation of add-on application software packages. A package to be installed in /opt must locate its static files in a separate /opt/<package> or /opt/<provider> directory tree, where <package> is a name that describes the software package and <provider> is the provider's LANANA registered name."
Did you read the section on /usr/local?
I don't know where all this /opt and company came from but.....
You are right. You don't know.
When I finally get to rebuilding TDE I will put the whole thing into /usr/local. It will not interfere with KDE4 and QT4 and as an added benifit I don't have to mess with PATH nor the linker path etc. It just works. ;)
Your system your rules.
Yes as it should be
May I suggest you think about changing /opt or where ever you installed this beast and place your work into /usr/local as well.
You may suggest, but it is a poor suggestion. How would you have a trinity-3.5.13, trinity-3.5.14, and a trinity-dev on the same system?
Well I have a couple of choices put 3.5.13 into /usr put 3.5.14 into /usr/local fixup PATH and I can run either. Also see above.
Do this in /usr/local:
lrwxrwxrwx 1 root root 9 Dec 14 21:55 qt -> qt-3.3.8d drwxr-xr-x 11 root root 4096 Dec 1 2005 qt-3.3.5 drwxr-xr-x 11 root root 4096 Nov 3 2007 qt-3.3.8 drwxr-xr-x 11 root root 4096 Apr 22 2007 qt-3.3.8-nomysql drwxr-xr-x 11 root root 4096 Dec 14 21:55 qt-3.3.8d drwxr-xr-x 12 root root 4096 Mar 5 2008 qt-4.3.4 drwxr-xr-x 13 root root 4096 May 21 2009 qt-4.5.0 drwxr-xr-x 13 root root 4096 Aug 18 2009 qt-4.5.2 drwxr-xr-x 14 root root 4096 Oct 12 2010 qt-4.7.0 drwxr-xr-x 14 root root 4096 Jan 10 15:04 qt-4.8.0
lrwxrwxrwx 1 root root 9 Aug 18 2009 kde -> kde-3.5.10 drwxr-xr-x 7 root root 4096 Dec 12 2006 kde-3.5.2 drwxr-xr-x 7 root root 4096 Aug 18 2009 kde-3.5.10 drwxr-xr-x 7 root root 4096 Dec 19 22:18 trinity -> trinity-3.5.13 drwxr-xr-x 7 root root 4096 Dec 19 12:34 trinity-dev drwxr-xr-x 5 root root 4096 Dec 18 21:06 trinity-3.5.13
I already do so a few symlinks and it done. I have read up on how this is done. I just usally use the package manager to this, then I don't have to mess with it.
In Summary I have a plan, between pacman package manager and a few symlinks I can do what you suggest and then some. I like flexibility ;)
My distro my rule, my computer my rules.
<warning a bit of a rant follows> ... /<warning a bit of a rant follows>
I understand your reasoning. I have run into path issues that are caused by installing to /opt/trinity and I have filed bug reports. As a team we need to resolve these types of bugs before R14. Even if the bugs prove to be PEBKAC, we need to provide that information on the wiki so people avoid these traps.
Installing to /usr/local won't solve all path problems --- when KDE4 is installed too. A challenge with Trinity and KDE4 coexisting is the names of so many apps and shared libraries have the same name.
Searching for apps is dependent upon the $PATH variable. Placing apps in /usr/local/bin means /usr/local/bin needs to be before /usr/bin in the search path, which normally is true. Yet how do users run KDE4 in that environment? Only full path names will resolve the problem because of the duplicate names. The same thing happens with installing to /opt/trinity. /opt/trinity/bin needs to be first in $PATH, but how do KDE4 users run their apps.
What happens in a multi-user system? I can solve these problems on a system with one user by removing KDE4 from the system. When I do that then I might as well build my packages to install to /usr rather than /usr/local or /opt/trinity.
I can't do that in a multi-user system because users have their desktop preferences. There also are people who run both Trinity and KDE4. How should they configure a system to avoid path conflicts and apps with the same name? The problem is all of those apps and libraries with the same name.
Part of the problem is the various Trinity *.desktop files default to only the executable name rather than using a full path. As long as Trinity is forced to play second fiddle with KDE4, then I think we should revise all *.desktop files to include full paths to the executables. This is something that needs to done during compiling.
These path conflicts are different than the problem I had with pkg-config and $CPLUS_INCLUDE_PATH. :) Configuring pkgconfig files is a matter of packaging and ensuring *.pc files are findable through the $PKG_CONFIG_PATH environment variable. The problem affecting my build environment is a weird anomaly that even if explainable, is just plain difficult to troubleshoot. My build environment was finding the *.pc files but something with the $CPLUS_INCLUDE_PATH variable causes breakage.
Rants are good to raise awareness. I like rants. :) I have raised some of these path conflict issues here before but all I received was silence. As a team we need to address various peculiarities users might experience when both KDE4 and Trinity are installed on the same system. As a team we need to ensure developers and packagers are testing in such an environment. If everybody merely rips KDE4 from their system to use Trinity then that is the same as sticking our heads in the sand. :)
If we stick our heads in the sand we get a bad reputation. :(
Darrell
On Thu, 19 Jan 2012 15:12:23 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
<warning a bit of a rant follows> ... /<warning a bit of a rant follows>
I understand your reasoning. I have run into path issues that are caused by installing to /opt/trinity and I have filed bug reports. As a team we need to resolve these types of bugs before R14. Even if the bugs prove to be PEBKAC, we need to provide that information on the wiki so people avoid these traps.
Installing to /usr/local won't solve all path problems --- when KDE4 is installed too. A challenge with Trinity and KDE4 coexisting is the names of so many apps and shared libraries have the same name.
Searching for apps is dependent upon the $PATH variable. Placing apps in /usr/local/bin means /usr/local/bin needs to be before /usr/bin in the search path, which normally is true. Yet how do users run KDE4 in that environment? Only full path names will resolve the problem because of the duplicate names. The same thing happens with installing to /opt/trinity. /opt/trinity/bin needs to be first in $PATH, but how do KDE4 users run their apps.
What happens in a multi-user system? I can solve these problems on a system with one user by removing KDE4 from the system. When I do that then I might as well build my packages to install to /usr rather than /usr/local or /opt/trinity.
I can't do that in a multi-user system because users have their desktop preferences. There also are people who run both Trinity and KDE4. How should they configure a system to avoid path conflicts and apps with the same name? The problem is all of those apps and libraries with the same name.
The solution used by Gentoo for installing KDE3 and KDE4 in parallel was to filter the $PATH variable in startkde by using sed--if the startkde for KDE3 was invoked, KDE4 directories would be filtered out of the path, and vice-versa. That fixes most of the problems you describe (invoking a KDE4 application while running KDE3/Trinity does require the full path to be given, but that's a minor flaw compared to not knowing which app you're going to be getting), although I admit it isn't elegant.
The solution used by Gentoo for installing KDE3 and KDE4 in parallel was to filter the $PATH variable in startkde by using sed--if the startkde for KDE3 was invoked, KDE4 directories would be filtered out of the path, and vice-versa. That fixes most of the problems you describe (invoking a KDE4 application while running KDE3/Trinity does require the full path to be given, but that's a minor flaw compared to not knowing which app you're going to be getting), although I admit it isn't elegant.
A challenge with that solution is when KDE4 apps are installed in /usr/bin. Tough to filter that location from the $PATH variable. :) I'm curious how that was achieved, unless in Gentoo KDE4 executables are installed someplace unique rather than /usr/bin.
I mentioned the *.desktop files. I haven't thought of a smooth or slick way to update those files on-the-fly when building packages. But in my proposed revised starttde script (bug report 675), I revised everything to full paths to avoid conflicts with KDE4 because that was exactly what was happening to me.
I'm starting to think that not using full paths in files such as the *.desktop files is an old habit that works a significant majority of the time but probably is a bad habit nonetheless.
Perhaps anything that gets installed in a non standard location like /opt should be built to use full paths everywhere? :)
Darrell
On Thu, 19 Jan 2012 16:31:50 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
The solution used by Gentoo for installing KDE3 and KDE4 in parallel was to filter the $PATH variable in startkde by using sed--if the startkde for KDE3 was invoked, KDE4 directories would be filtered out of the path, and vice-versa. That fixes most of the problems you describe (invoking a KDE4 application while running KDE3/Trinity does require the full path to be given, but that's a minor flaw compared to not knowing which app you're going to be getting), although I admit it isn't elegant.
A challenge with that solution is when KDE4 apps are installed in /usr/bin. Tough to filter that location from the $PATH variable. :) I'm curious how that was achieved, unless in Gentoo KDE4 executables are installed someplace unique rather than /usr/bin.
Yes, the installations are made to /usr/kde/[version]/bin under Gentoo... however, doesn't the system search the $PATH directories in order? Placing the Trinity bin directory first should cause its contents to take precedence over what's in /usr/bin if there's a naming conflict, shouldn't it?
Yes, the installations are made to /usr/kde/[version]/bin under Gentoo...
Aha. Okay.
however, doesn't the system search the $PATH directories in order? Placing the Trinity bin directory first should cause its contents to take precedence over what's in /usr/bin if there's a naming conflict, shouldn't it?
Should, but I can think of one bug report right now where that doesn't work: bug report 657. The only way I can get kword and kpresenter to work from the T-Menu is to use the full path. Oddly, the other apps in koffice start just fine from the T-Menu.
Maybe this isn't a path problem, but if I knew I would not have filed the report. :)
Darrell
On Thursday 19 January 2012 06:12:23 pm Darrell Anderson wrote:
<warning a bit of a rant follows> ... /<warning a bit of a rant follows>
I understand your reasoning. I have run into path issues that are caused by installing to /opt/trinity and I have filed bug reports. As a team we need to resolve these types of bugs before R14. Even if the bugs prove to be PEBKAC, we need to provide that information on the wiki so people avoid these traps.
Well yes, but TDE should be able to be built into any directory place withn in reason and it should work.
Installing to /usr/local won't solve all path problems --- when KDE4 is installed too. A challenge with Trinity and KDE4 coexisting is the names of so many apps and shared libraries have the same name.
It helps me get past the path issues and that uglyness, then I am only left to fight with the "real" issues and test it. I came to this position after the trouble I had trying to build the packages that used autotools. That was horrible. What I ended up doing was to simplify by ripping out all the path/pkg-config/linker and god only knows what else. Now it mostly ujst builds. If I have a header file or lib that can not be found I only need to look at that. There are a lot of variables/paths tweaks I see in most everybodies scripts that I don't need or have a problem with.
Would having tde able to be build solidily with a minimum amount of trouble be good and then all the energy spent just trying to get it built could be directed at getting tit to work with KDE4 be better?
Searching for apps is dependent upon the $PATH variable. Placing apps in /usr/local/bin means /usr/local/bin needs to be before /usr/bin in the search path, which normally is true. Yet how do users run KDE4 in that environment? Only full path names will resolve the problem because of the duplicate names. The same thing happens with installing to /opt/trinity. /opt/trinity/bin needs to be first in $PATH, but how do KDE4 users run their apps.
Yes I know that, but until the executable names are changed I don't see how this will ever be solved completely. ( see below )
What happens in a multi-user system? I can solve these problems on a system with one user by removing KDE4 from the system. When I do that then I might as well build my packages to install to /usr rather than /usr/local or /opt/trinity.
I can't do that in a multi-user system because users have their desktop preferences. There also are people who run both Trinity and KDE4. How should they configure a system to avoid path conflicts and apps with the same name? The problem is all of those apps and libraries with the same name.
Yes I know.
Part of the problem is the various Trinity *.desktop files default to only the executable name rather than using a full path. As long as Trinity is forced to play second fiddle with KDE4, then I think we should revise all *.desktop files to include full paths to the executables. This is something that needs to done during compiling.
Then TDE is tied into being in a certain place unless the packager handles changing all the pathing issues/changes in the desktop files. Sounds ugly.
These path conflicts are different than the problem I had with pkg-config and $CPLUS_INCLUDE_PATH. :) Configuring pkgconfig files is a matter of packaging and ensuring *.pc files are findable through the $PKG_CONFIG_PATH environment variable. The problem affecting my build environment is a weird anomaly that even if explainable, is just plain difficult to troubleshoot. My build environment was finding the *.pc files but something with the $CPLUS_INCLUDE_PATH variable causes breakage.
This is one of the reasons I changed to using /usr/local. I don't have to use $CPLUS_INCLUDE_PATH or any of the "other nonsense" to get tde to build.
Have a look at my scripts on github or gitorius. You will see they don't have a lot of that kind of thing going on. They are pretty straight forward. configure && make && and install, package it up and then next package. After I slayed the qt3 problem all was good.
Rants are good to raise awareness. I like rants. :) I have raised some of these path conflict issues here before but all I received was silence. As a team we need to address various peculiarities users might experience when both KDE4 and Trinity are installed on the same system. As a team we need to ensure developers and packagers are testing in such an environment. If everybody merely rips KDE4 from their system to use Trinity then that is the same as sticking our heads in the sand. :)
Not really, it needs to be able to be built easily as well as mostly finished. Don't want to many beasts to slay at one time, if you get my drift.
If we stick our heads in the sand we get a bad reputation. :(
Sure, my goals are a but different. Keep it simple Get TDE stable/buildable until it get to the point that it builds on most distros. Then go wild on bending and breaking it. ;)
There is a lot of work left to do. Including intergrating into a system with other desktop GUIs.
I see stable first then integrate.
Beat you to the punch. :)
I might not be a crack developer, but I can troubleshoot with some of the best. ;)
I know. :-)
You might not believe the cause of this entire problem. Are you ready for this?
Setting the $CPLUS_INCLUDE_PATH in the build environment prevents pkg-config from running properly. The moment I commented out that export command in my master script, the TQT_INCLUDE_DIRS internal variable began populating automatically.
Okay, for the record: Woo-hoo!
Now, why does the $CPLUS_INCLUDE_PATH environment variable, or the contents thereof, affect how pkg-config runs?
Second, should I be setting that environment variable?
Here is my normal setting for that variable:
CPLUS_INCLUDE_PATH: /usr/include/tqt:/usr/lib/qt3/include:/usr/include
Those locations are legitimate.
I set $CMAKE_INCLUDE_PATH to the same, but I did not start setting that variable until recently. That is, this TQT_INCLUDE_DIRS problem existed long before I started setting the $CMAKE_INCLUDE_PATH variable. The $CPLUS_INCLUDE_PATH is the cause.
Ideas?
Darrell
Don't set CPLUS_INCLUDE_PATH?
Seriously, I'm not sure why you set that variable. I never heard of it before, and usually the safest way to get includes added to the compiler flags is via CXXFLAGS and CFLAGS.
If you have a specific reason for setting CPLUS_INCLUDE_PATH then that is different.
Tim
On Thu, 19 Jan 2012 17:25:44 -0600 "Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:
Beat you to the punch. :)
I might not be a crack developer, but I can troubleshoot with some of the best. ;)
I know. :-)
You might not believe the cause of this entire problem. Are you ready for this?
Setting the $CPLUS_INCLUDE_PATH in the build environment prevents pkg-config from running properly. The moment I commented out that export command in my master script, the TQT_INCLUDE_DIRS internal variable began populating automatically.
Okay, for the record: Woo-hoo!
Now, why does the $CPLUS_INCLUDE_PATH environment variable, or the contents thereof, affect how pkg-config runs?
Second, should I be setting that environment variable?
Here is my normal setting for that variable:
CPLUS_INCLUDE_PATH: /usr/include/tqt:/usr/lib/qt3/include:/usr/include
Those locations are legitimate.
I set $CMAKE_INCLUDE_PATH to the same, but I did not start setting that variable until recently. That is, this TQT_INCLUDE_DIRS problem existed long before I started setting the $CMAKE_INCLUDE_PATH variable. The $CPLUS_INCLUDE_PATH is the cause.
Ideas?
Darrell
Don't set CPLUS_INCLUDE_PATH?
Seriously, I'm not sure why you set that variable. I never heard of it before, and usually the safest way to get includes added to the compiler flags is via CXXFLAGS and CFLAGS.
I think he sets it because the Slackware official Qt3 build scripts we (I and Darrell) based ours on installs a profile script in /etc/profile.d that sets CPLUS_INCLUDE_PATH. I don't know why Slackware sets this variable but it has done it since at least 2003 and still does today (in the Qt4 package).
If you have a specific reason for setting CPLUS_INCLUDE_PATH then that is different.
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Seriously, I'm not sure why you set that
variable. I never heard of
it before, and usually the safest way to get includes
added to the
compiler flags is via CXXFLAGS and CFLAGS.
I think he sets it because the Slackware official Qt3 build scripts we (I and Darrell) based ours on installs a profile script in /etc/profile.d that sets CPLUS_INCLUDE_PATH. I don't know why Slackware sets this variable but it has done it since at least 2003 and still does today (in the Qt4 package).
Yeah, what you said (as I just shared in a concurrent post. :) )
This raises some questions. Is the CPLUS_INCLUDE_PATH environment variable necessary at run for qt3 to behave? Or is this some kind of throw back to the early days of qt3 that has since become obsolete?
In another bug report (637) I submitted several patches that are used to build qt3 in Slackware. We discovered that the mysql.h patch is unnecessary. All that is needed is to add the -I/usr/include/mysql configure option. My guess is that patch was a carryover from days long past when the -I/usr/include/mysql configure option did not exist. Whenever a new release of qt3 became available, the first thing most people do is build with their existing build script. The patch always worked but became unnecessary and nobody noticed.
Similarly, in that same bug report, was a long standing patch for resetting the QT_BUILTIN_GIF_READER variable to 1. That patch goes back to the day when there were legal issues with gif patents and the reason for resetting that variable was to use qt3's built in gif support. Those legal issues no longer exist and the patch no longer is necessary. Further, qt3 has since then added a -qt-gif configure option that does the same thing.
So now I wonder whether CPLUS_INCLUDE_PATH is necessary during run time or whether that is a throw back to the early days of qt3. I think that depends upon where the qt3 header files get installed. Normally they are installed to the non standard location of $PREFIX/qt3/lib/include. Yet like the mysql problem, the installation location for the qt3 headers can be defined in the build configuration with -headerdir /usr/include/qt3. With the headers installed in a standard /usr/include subdirectory, building other apps that need qt3 should no longer need the CPLUS_INCLUDE_PATH variable.
I think a lot of what has transpired here is just old fashioned habits. Today probably nobody knows the original reasons for doing things that way. Why? "I don't know, that's just the way we've always done things around here." (http://www.simpleliberty.org/taota/introduction.htm)
Darrell
Seriously, I'm not sure why you set that
variable. I never heard of
it before, and usually the safest way to get includes
added to the
compiler flags is via CXXFLAGS and CFLAGS.
I think he sets it because the Slackware official Qt3 build scripts we (I and Darrell) based ours on installs a profile script in /etc/profile.d that sets CPLUS_INCLUDE_PATH. I don't know why Slackware sets this variable but it has done it since at least 2003 and still does today (in the Qt4 package).
Yeah, what you said (as I just shared in a concurrent post. :) )
This raises some questions. Is the CPLUS_INCLUDE_PATH environment variable necessary at run for qt3 to behave? Or is this some kind of throw back to the early days of qt3 that has since become obsolete?
Not needed at runtime; it must be obsolete.
Tim
Don't set CPLUS_INCLUDE_PATH?
I am now doing that. :)
Seriously, I'm not sure why you set that variable. I never heard of it before, and usually the safest way to get includes added to the compiler flags is via CXXFLAGS and CFLAGS.
Long ago in a galaxy far away, when I first joined the project, I noticed the variable being set in the /etc/profile.d/qt.sh script that came with the Slackware qt3 package. I presumed the variable was important. Of course, that script is for run time and not for compiling. Over time I have been learning to strip many environment variables from within my build environment, but that one slipped through unnoticed until this mess surfaced.
Maybe we should have a short snippet in our wiki with what are appropriate environment variables, which ones to avoid, and what is appropriate for CXX/CFLAGS?
If you have a specific reason for setting CPLUS_INCLUDE_PATH then that is different.
Not any more! :)
Darrell
Don't set CPLUS_INCLUDE_PATH?
I am now doing that. :)
Seriously, I'm not sure why you set that variable. I never heard of it before, and usually the safest way to get includes added to the compiler flags is via CXXFLAGS and CFLAGS.
Long ago in a galaxy far away, when I first joined the project, I noticed the variable being set in the /etc/profile.d/qt.sh script that came with the Slackware qt3 package. I presumed the variable was important. Of course, that script is for run time and not for compiling. Over time I have been learning to strip many environment variables from within my build environment, but that one slipped through unnoticed until this mess surfaced.
Maybe we should have a short snippet in our wiki with what are appropriate environment variables, which ones to avoid, and what is appropriate for CXX/CFLAGS?
Good idea! At least make mention of this problematic variable, as it took quite a while (and a couple of bug reports) for both of us to even begin to figure out what was going on. ;-)
Tim
Maybe we should have a short snippet in our wiki with
what are appropriate
environment variables, which ones to avoid, and what
is appropriate for
CXX/CFLAGS?
Good idea! At least make mention of this problematic variable, as it took quite a while (and a couple of bug reports) for both of us to even begin to figure out what was going on. ;-)
I can add a snippet about the CPLUS_INCLUDE_PATH variable, but I don't the root cause of why the variable causes pkg-config to gag.
I'm nowhere close to being qualifed to write something about CXX/CFLAGS. Somebody else (not you) should provide a paragraph addressing those variables.
I don't know where to begin with respect to addressing other variables. Perhaps if several people here add their two cents or euros to what they use and what they avoid I then could massage that information into something useful. :)
Darrell
Darrell Anderson wrote:
I'm nowhere close to being qualifed to write something about CXX/CFLAGS. Somebody else (not you) should provide a paragraph addressing those variables.
Read the documentation for gcc and make. They control how a program is compiled and can make a huge difference. The developer should know what the options do before they are set. Variables like CFLAGS and CXXFLAGS are often set or modified in a Makefile.
For qt based apps, it would also be helpful to read through the qmake manual as that generally is used, via a .pro file, to generate the Makefile for an application or library.
-- Bruce
I'm nowhere close to being qualifed to write something
about
CXX/CFLAGS. Somebody else (not you) should provide a
paragraph
addressing those variables.
Read the documentation for gcc and make. They control how a program is compiled and can make a huge difference. The developer should know what the options do before they are set. Variables like CFLAGS and CXXFLAGS are often set or modified in a Makefile.
For qt based apps, it would also be helpful to read through the qmake manual as that generally is used, via a .pro file, to generate the Makefile for an application or library.
I have no problem with learning, but an RTFM response rather than helping is lame. :)
Darrell
Darrell Anderson wrote:
I'm nowhere close to being qualifed to write something
about
CXX/CFLAGS. Somebody else (not you) should provide a
paragraph
addressing those variables.
Read the documentation for gcc and make. They control how a program is compiled and can make a huge difference. The developer should know what the options do before they are set. Variables like CFLAGS and CXXFLAGS are often set or modified in a Makefile.
For qt based apps, it would also be helpful to read through the qmake manual as that generally is used, via a .pro file, to generate the Makefile for an application or library.
I have no problem with learning, but an RTFM response rather than helping is lame. :)
It does help if you don't know where to go to learn. The problem with self learning is that it tends to be hit and miss. Without an understanding of the general architecture, mistakes will be made.
I don't have time to be a Trinity core developer. If you don't like the comments, I can avoid all replies.
-- Bruce
I have no problem with learning, but an RTFM response
rather than helping is lame. :)
It does help if you don't know where to go to learn. The problem with self learning is that it tends to be hit and miss. Without an understanding of the general architecture, mistakes will be made.
In almost three decades of working in tech writing and training, I have learned a simple lesson: telling people to RTFM doesn't work. :)
Even people who are motivated to learn need guidance.
A method that works well to help people learn is to guide them through the problem alongside the documentation rather than just tell them to RTFM.
A short description about C/CXXFLAGS with respect to Trinity and links to sections of relative documentation would have helped. That's all.
Darrell
Darrell Anderson wrote:
Don't set CPLUS_INCLUDE_PATH?
I am now doing that. :)
Seriously, I'm not sure why you set that variable. I never heard of it before, and usually the safest way to get includes added to the compiler flags is via CXXFLAGS and CFLAGS.
Long ago in a galaxy far away, when I first joined the project, I noticed the variable being set in the /etc/profile.d/qt.sh script that came with the Slackware qt3 package. I presumed the variable was important.
CPLUS_INCLUDE_PATH is an integral part of gcc, specifically g++. See the man page.
Of course, that script is for run time and not for compiling.
Then CPLUS_INCLUDE_PATH doesn't mean anything.
-- Bruce
-
/dev/ammo42 -
Baho Utot -
Bruce Dubbs -
Darrell Anderson -
E. Liddell -
Timothy Pearson