Tim, Serghei, Darrell,
What are your thoughts on how we should handle differing versions of libtool/auto... with tde building? The tdeutils build failure has really brought this to light. libtool 2.4.2-4 in Arch contains parsing functions that do not exist in the libtool version in tde GIT that causes the libtool process to attempt to use variable that are uninitialized and not declared resulting in build failures.
For tdeutils the build fails with the call to "$to_host_file_cmd $1". The to_host_file_cmd isn't part of libtool in TDE. Evidently, the new libtool tries to call to_host_file_cmd on every source it compiles. Since to_host_file_cmd is not defined anywhere -- it bombs.
The file name to toolchain parsing functions are at the end of the arch libtool.m4 file:
<snip> to_host_file_cmd=$lt_cv_to_host_file_cmd AC_MSG_RESULT([$lt_cv_to_host_file_cmd]) _LT_DECL([to_host_file_cmd], [lt_cv_to_host_file_cmd], [0], [convert $build file names to $host format])dnl
AC_MSG_CHECKING([how to convert $build file names to toolchain format]) AC_CACHE_VAL(lt_cv_to_tool_file_cmd, [#assume ordinary cross tools, or native build. lt_cv_to_tool_file_cmd=func_convert_file_noop case $host in *-*-mingw* ) case $build in *-*-mingw* ) # actually msys lt_cv_to_tool_file_cmd=func_convert_file_msys_to_w32 ;; esac ;; esac ]) to_tool_file_cmd=$lt_cv_to_tool_file_cmd AC_MSG_RESULT([$lt_cv_to_tool_file_cmd]) _LT_DECL([to_tool_file_cmd], [lt_cv_to_tool_file_cmd], [0], [convert $build files to toolchain format])dnl ])# _LT_PATH_CONVERSION_FUNCTIONS
I guess the question is "does the libtool in tde need to be updated?" ..or.. is there some way to just to bypass the version inconsistency? It might be arch that is having issues today, but it will be the remainder of the distros that have the issue after a libtool update. I have tried several times to get familiar with cmake conversion, but as of today, I don't have the tools to tackle something like tdeutils. I don't know if that would provide a better solution than trying to fix libtool or how much work that would be.
What are the thoughts of the experts?
I guess the question is "does the libtool in tde need to be updated?" ..or.. is there some way to just to bypass the version inconsistency? It might be arch that is having issues today, but it will be the remainder of the distros that have the issue after a libtool update. I have tried several times to get familiar with cmake conversion, but as of today, I don't have the tools to tackle something like tdeutils. I don't know if that would provide a better solution than trying to fix libtool or how much work that would be.
What are the thoughts of the experts?
First thought is I am not an expert!
Second thought is according to the instructions at the wiki, the way to use libtools is to use the libtool.m4 and ltmain.sh installed on the system to regenerate the files and not the files provided in each module's sources. Therefore we don't really use libtools from any upstream sources. Are you doing that?
Third thought is although I appreciate your frustrations, seems to me the immediate focus for R14 should be the bug tracker and not bleeding edge I want-my-system-to-crash every-other-day distros. Perhaps roll back your system to a previous version and likely most or all of these problems disappear? Yes, we still need to address the problems --- down the road after R14, but bleeding edge rolling distros should not be dictating project focus. We can't keep pace now let alone with bleeding edge.
Darrell
On Mar 19, 2012 10:15 PM, "Darrell Anderson" humanreadable@yahoo.com wrote:
I guess the question is "does the libtool in tde need to be updated?" ..or.. is there some way to just to bypass the version inconsistency? It might be arch that is having issues today, but it will be the remainder of the distros that have the issue after a libtool update. I have tried several times to get familiar with cmake conversion, but as of today, I don't have the tools to tackle something like tdeutils. I don't know if that would provide a better solution than trying to fix libtool or how much work that would be.
What are the thoughts of the experts?
First thought is I am not an expert!
Second thought is according to the instructions at the wiki, the way to
use libtools is to use the libtool.m4 and ltmain.sh installed on the system to regenerate the files and not the files provided in each module's sources. Therefore we don't really use libtools from any upstream sources. Are you doing that?
Third thought is although I appreciate your frustrations, seems to me the
immediate focus for R14 should be the bug tracker and not bleeding edge I want-my-system-to-crash every-other-day distros.
Arch Linux uses the latest versions provided by upstream projects. It is not generally bleeding or breaking, just current. Often current versions include bug and security fixes. I don't like people who bash Arch :)
Perhaps roll back your system to a previous version and likely most or all of these problems disappear? Yes, we still need to address the problems --- down the road after R14, but bleeding edge rolling distros should not be dictating project focus. We can't keep pace now let alone with bleeding edge.
Because some distros (like Ubuntu ) are woefully out of date, doesn't mean everyone is. Trinity needs to work across the board. If its breaking in Arch, it most likely will break Ubuntu debian or slack later
Sorry for the rant, Calvin
On 03/19/2012 09:14 PM, Darrell Anderson wrote:
First thought is I am not an expert!
Second thought is according to the instructions at the wiki, the way to use libtools is to use the libtool.m4 and ltmain.sh installed on the system to regenerate the files and not the files provided in each module's sources. Therefore we don't really use libtools from any upstream sources. Are you doing that?
Third thought is although I appreciate your frustrations, seems to me the immediate focus for R14 should be the bug tracker and not bleeding edge I want-my-system-to-crash every-other-day distros. Perhaps roll back your system to a previous version and likely most or all of these problems disappear? Yes, we still need to address the problems --- down the road after R14, but bleeding edge rolling distros should not be dictating project focus. We can't keep pace now let alone with bleeding edge.
Darrell
I agree, with all points. Calvin has valid points as well. What I'm trying to get my arms around is what needs to be fixed so TDE builds with current upstream packages. Granted, this is a moving target, and I've considered moving to slack or debian for R14 testing, but that would simply interject more delay. Bugs need squashing, but it is very difficult to work bugs if there is nothing to test the bugs against.
For the autotools packages, I follow the HowToBuild wiki to the tee and that has exposed the problem with the current libtool.m4 not working the tde libtool version. After copying the ltmain.sh and libtool.m4 files from the system to the /admin dir, the libtool file generated by:
make -f admin/Makefile.common
is simply broken and references undeclared variables preventing tdeutils (and probably most other autotools packages from building at all) I've put this out to the Arch developers and their input suggests the versions are simply incompatible due to the difference in forks between the libtool versions being used.
The libtool version used by Arch is libtool 2.4.2, which according to http://www.gnu.org/software/libtool/ is the latest 'stable' version. Not a git or svn or other cvs version of libtool, but the stable version.
Yes, that is frustrating because it shows that the TDE autotool/libtool code is no longer compatible with the current libtool/autofoo tools. That's just something we have to overcome. I think cmake conversion would resolve this issue, but I don't even know where to start. I've just skipped tdeutils for now, but that will be a mandatory package to fix building on before R14 or building will break for all distros when they update to the current stable libtool.
Yes, that is frustrating because it shows that the TDE autotool/libtool code is no longer compatible with the current libtool/autofoo tools. That's just something we have to overcome. I think cmake conversion would resolve this issue, but I don't even know where to start. I've just skipped tdeutils for now, but that will be a mandatory package to fix building on before R14 or building will break for all distros when they update to the current stable libtool.
Yes, we have to deal with this sooner or later. I was only offering that later is more palatable if we want to release R14 in a timely manner.
Converting to cmake would resolve many issues. I have raised that topic too. I have asked for somebody to write a basic how-to for the wiki so others can help with the process. A few people have noted there are scripts to help with the automation. Those of us new to the process could use the wiki article to start converting smaller packages.
We have no quality assurance plan to ensure that cmake conversions are complete. I filed a bug report against all cmake packages because none support kerberos (krb5). Reading past list threads and the related etherpad indicates many little pieces here and there are missing. What has been converted is wonderful and does indeed work. I'm grateful for that effort. I'm just saying we need a check list to ensure the minute details are converted too. I am aware that a full conversion requires a person to have all related software installed in order to test. A check list helps others with that software to fill the remaining gaps.
That is why I am not in favor of destroying any of the automake files after a cmake conversion. Those files serve as our guide.
Similarly, all or most of the TDE packages come with a text file called subdirs, which was used in the KDE3 days with the DO_NOT_COMPILE environment variable to determine which package components to build. That subdirs text file is a good start for a check list. Each component listed in the file needs an equivalent -DWITH_COMPONENT build option.
When packages no longer build because of libtools/automake updates then file the bug report. Tag the report as Blocker P1 and note in the comments the problem is a build issue.
Darrell
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin