19 Mar
2012
19 Mar
'12
8:06 p.m.
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?
--
David C. Rankin, J.D.,P.E.
20 Mar
20 Mar
2:14 a.m.
New subject: [trinity-devel] Howto handle differing versions of libtool in TDE builds
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
4:15 a.m.
New subject: [trinity-devel] Howto handle differing versions of libtool in TDE builds
On Mar 19, 2012 10:15 PM, "Darrell Anderson" <humanreadable(a)yahoo.com wrote:
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?
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
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.
5:48 a.m.
New subject: [trinity-devel] Howto handle differing versions of libtool in TDE builds
On 03/19/2012 09:14 PM, Darrell Anderson wrote:
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.
--
David C. Rankin, J.D.,P.E.
1:32 p.m.
New subject: [trinity-devel] Howto handle differing versions of libtool in TDE builds
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
4737
days inactive
4738
days old
4 comments
3 participants
participants (3)
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin