Bug 229821 - emerge dev-util/gambas-2.7.0 fails with libtool-2
|
Bug#:
229821
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: darkside@gentoo.org
|
Reported By: gapon@nano.cz
|
|
Component: Applications
|
|
|
URL:
|
|
Summary: emerge dev-util/gambas-2.7.0 fails with libtool-2
|
|
Keywords: EBUILD
|
|
Status Whiteboard:
|
|
Opened: 2008-06-27 20:15 0000
|
config.status: config.h is unchanged
make all-am
make[5]: Entering directory
`/var/tmp/portage/dev-util/gambas-2.7.0/work/gambas2-2.7.0/main/libltdl'
/bin/sh ./libtool --tag=CC --mode=compile i686-pc-linux-gnu-gcc
-DHAVE_CONFIG_H -I. -O2 -march=prescott -pipe -c -o ltdl.lo ltdl.c
./libtool: line 466: CDPATH: command not found
./libtool: line 1158: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.2.4, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.4
libtool: and run autoconf again.
make[5]: *** [ltdl.lo] Error 63
make[5]: Leaving directory
`/var/tmp/portage/dev-util/gambas-2.7.0/work/gambas2-2.7.0/main/libltdl'
make[4]: *** [all] Error 2
make[4]: Leaving directory
`/var/tmp/portage/dev-util/gambas-2.7.0/work/gambas2-2.7.0/main/libltdl'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/var/tmp/portage/dev-util/gambas-2.7.0/work/gambas2-2.7.0/main'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/var/tmp/portage/dev-util/gambas-2.7.0/work/gambas2-2.7.0/main'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/dev-util/gambas-2.7.0/work/gambas2-2.7.0'
make: *** [all] Error 2
Reproducible: Always
cattie ~ # emerge --info
Portage 2.2_rc1 (default-linux/x86/2006.1, gcc-4.3.1, glibc-2.8_p20080602-r0,
2.6.25-gentoo-r5 i686)
=================================================================
System uname:
Linux-2.6.25-gentoo-r5-i686-Genuine_Intel-R-_CPU_T2600_@_2.16GHz-with-glibc2.0
Timestamp of tree: Fri, 27 Jun 2008 13:36:01 +0000
app-shells/bash: 3.2_p39
dev-java/java-config: 1.3.7, 2.1.6
dev-lang/python: 2.4.4-r13, 2.5.2-r5
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 2.0.0
sys-apps/openrc: 0.2.5
sys-apps/sandbox: 1.2.18.1-r2
sys-devel/autoconf: 2.13, 2.62
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2,
1.10.1-r1
sys-devel/binutils: 2.18-r2
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool: 2.2.4
virtual/os-headers: 2.6.25-r4
ACCEPT_KEYWORDS="x86 ~x86"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=prescott -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/
/etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release
/etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/
/etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo
/etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-O2 -march=prescott -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="collision-protect distlocks fixpackages metadata-transfer
parallel-fetch preserve-libs sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS=" http://ftp.sh.cvut.cz/MIRRORS/gentoo/gentoo
http://gentoo.inode.at/ ftp://213.186.33.38/gentoo-distfiles/
http://gentoo.inf.elte.hu/"
LANG="cs_CZ.UTF-8"
LC_ALL="cs_CZ.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--sort-common"
LINGUAS="cs"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --stats --timeout=180 --exclude=/distfiles
--exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/local/portage/bzr-gentoo-overlay"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X a52 aac aalib accessibility acpi alsa apache2 aspnet aspnetedit avi
bash-completion berkdb bluetooth bzip2 cdr cli cracklib crypt css cups dbus
directfb divx4linux dri dvd dvdr dvdread encode examples exif faad fam fbcon
ffmpeg firebird firefox fortran ftp gdbm gif git gnutls gpm gstreamer gtk gtk2
hal iconv imap inotify ipod ipv6 isdnlog jabber java java5 java6 jpeg jpeg2k
jython kde kdeenablefinal laptop ldap libnotify logitech-mouse logrotate midi
mmx mmx2 mng mono moonlight mp3 mpeg mplayer mudflap mysql ncurses
networkmanager nls nptl nptlonly nsplugin nvidia ogg opengl openmp oss pam
pcmcia pcre perl png pnp postgres ppds pppd python qt qt3 qt4 quicktime
readline reflection ruby samba sasl sdl seamonkey session smp spl sqlite
sqlite3 sse sse2 ssl subversion svg swig tcpd theora tiff truetype unicode usb
utf8 vim vim-syntax vorbis wifi wireshark x264 x86 xcb xine xinerama xorg
xscreensaver xv xvid zlib zsh-completion" ALSA_CARDS="hda-intel"
ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file
hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route
share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest
authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default
authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs
dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter
headers ident imagemap include info log_config logio mem_cache mime mime_magic
negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite
setenvif so speling status unique_id userdir usertrack vhost_alias"
CAMERAS="ptp2 canon" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics"
KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001
mtxorb ncurses text" LINGUAS="cs" USERLAND="GNU" VIDEO_CARDS="nvidia nv vga
vesa fbdev"
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_COMPRESS,
PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I just added this package and it worked fine with libtool-1.5, if anyone has a
fix please let me know and I will check it out. Thanks.
Well, the problem is the silly way they must have constructed acinclude.m4.
To fix it, you have to remove from acinclude.m4 all the lines from
the start of the DOLT macro (I don't think it's necessary to explain the
silliness that is dolt) up to the line starting with "dnl Like
AC_CHECK_HEADER".
Then eautoreconf should work properly.
Which one is the DOLT macro? I found "dnl Like AC_CHECK_HEADER" but I do not
know how far the file needs to be cut.
(Note to self: Remember to look at this)
Created an attachment (id=160125) [details]
gambas-2.7.0-r1.ebuild.patch
I am not sure if this is the right way to do it at all, but it goes all the way
through to install. I have not tried merging it.
I also put in a couple of minor enhancements. Hopefully those can be adopted
at least.
I worked on amd64 and I think the ebuild should be keyworded ~amd64.
(In reply to comment #6)
> Created an attachment (id=160125) [edit] [details]
> gambas-2.7.0-r1.ebuild.patch
>
> I am not sure if this is the right way to do it at all, but it goes all the way
> through to install. I have not tried merging it.
>
> I also put in a couple of minor enhancements. Hopefully those can be adopted
> at least.
>
> I worked on amd64 and I think the ebuild should be keyworded ~amd64.
>
Cool. It looks like you fixed all of the 'known' issues as presented in bug
#146871. I'll test abit and see what happens.
Ouch, that's some nasty seding, but looks like it
should have the desired effect.
However, it won't work with libtool 1.5, something bit more
conservative may be required.
You cut the correct block and DOLT macro was the one directly above
libtool.m4.
I call DOLT silly, cause it was created after libtool 2.2 was released
and while it had a significant performance gain over libtool 1.5 (while loosing
some portability), that gain was not-so-significant over 2.2.
Answer was late, cause I wasn't CC'd to this but.
I wonder if/when libtool upstream will address that AC_CONFIG_SUBDIRS libltdl
incompability, BTW.
When I was updating the ebuild I was not looking for compatibility with libtool
1.5. That is why there is a depend (not necessarily the proper kind) on
libtool 2.2. If 1.5 compatibility is necessary, I could downgrade and work on
it, but I have very little experience with libtool or autotools.
About the seding, I am not sure when a "sed" patch is more appropriate than a
regular ".patch". A maintainer with experience would know better. This is
only the second ebuild I have worked on.
Thanks for answering my question for the DOLT macro. Appreciated.
(In reply to comment #10)
> When I was updating the ebuild I was not looking for compatibility with libtool
> 1.5. That is why there is a depend (not necessarily the proper kind) on
> libtool 2.2. If 1.5 compatibility is necessary, I could downgrade and work on
> it, but I have very little experience with libtool or autotools.
Ah, well. We have to maintain compat until libtool-1.5 isn't in the tree
anymore. And since libtool is an "implicit dependency", an ebuild shouldn't
really depend on any version of it.
> About the seding, I am not sure when a "sed" patch is more appropriate than a
> regular ".patch". A maintainer with experience would know better. This is
> only the second ebuild I have worked on.
Mainly, readability. If you think that some people might not understand the
sed'ing then you should make it a patch. Also, length. If the seding spans for
multiple lines or multiple times, it is probably more appropriate to do a
patch.
> Thanks for answering my question for the DOLT macro. Appreciated.
Created an attachment (id=161148) [details]
files/gambas-2.7.0-r1-gb.qt-QT_LDFLAGS.patch
.patch version of the previous sed patch
Upstream may/should apply something similar in the future or I am not
understanding the build system
Created an attachment (id=161149) [details]
files/gambas-2.7.0-r1-help-GB_INIT_SHORT.patch
fixes build failure
Upstream may/should apply something similar in the future or I am not
understanding the build system
(In reply to comment #16)
> Created an attachment (id=161155) [edit] [details]
> gambas-2.7.0-r1.ebuild.patch
>
> Minor additions/changes from previous patch
> Tested to "install" with libtool 1.5 and 2.2 on amd64
>
Alright, I have this in my local testing overlay. I will get to it soon,
promise.
Gambas 2.8.0 was released yesterday. I will not be able to look at it for at
least two days. Please post if there is anything I need to know before I start
updating the ebuild. I believe slot Qt dependencies are now required, about
which I need to read more.
Created an attachment (id=163349) [details]
gambas-2.8.0.ebuild
Version bump
- implemented "Reducing eautoreconf"
- enabled configure caching
- slot dependency for Qt
- new patches
- minor improvements
Tested to "install" with libtool 2.2, but I should not have broken
compatibility, on amd64 with gcc 4.2.
gambas-2.8.0.ebuild works as gambas-2.8.1.ebuild without any changes.
Could the reporter add EBUILD to the keywords since there is a user submitted
ebuild here. I am not allowed to change that.
(In reply to comment #24)
> gambas-2.8.0.ebuild works as gambas-2.8.1.ebuild without any changes.
>
> Could the reporter add EBUILD to the keywords since there is a user submitted
> ebuild here. I am not allowed to change that.
>
Compiling now. As promised, extremely late and I am a slacker...I know. Ebuild
looks fine enough and passes my QA. Will commit afte rI am done compiling (gcc
with USE-libffi as well), along with all those patches. Would you be interested
in submitting those patches upstream so we don't have to have 10 patches
floating around?
Anyway, I also need to remove gambas-1*, is everyone confident that
gambas-2.8.1 suits their needs? It will be the only one left because I want to
remove 2.7.0 as well.
(In reply to comment #25)
> Compiling now. As promised, extremely late and I am a slacker...I know. Ebuild
> looks fine enough and passes my QA. Will commit afte rI am done compiling (gcc
> with USE-libffi as well), along with all those patches. Would you be interested
> in submitting those patches upstream so we don't have to have 10 patches
> floating around?
Update: Compiled fine remotely. Just need to verify that it works properly when
I get home.
I will look for the proper contact and try to submit the non-Gentoo-specific
ones upstream. Getting them accepted is something else.
Can you modify the ebuild such that I don't get this error?
%% gambas2
ERROR: ld.so: object 'libqt-mt.so.3' from LD_PRELOAD cannot be preloaded:
ignored.
ERROR: #27: Cannot load component 'gb.qt': cannot find library file
Should the qt'ness be forced, non-optional?
Test case is compiled only with: USE="bzip2 gtk pcre zlib" the rest are
disabled.
Thanks.
Created an attachment (id=163954) [details]
patch attempting to fix new run-time error
I am not exactly sure why this is happening. This code in
/var/tmp/portage/dev-util/gambas-2.8.1/work/gambas2-2.8.1/gb.gtk/src
CTreeView.cpp-851-static void init_settings()
CTreeView.cpp-852-{
CTreeView.cpp-853- static bool init = false;
CTreeView.cpp-854-
CTreeView.cpp-855- if (init)
CTreeView.cpp-856- return;
CTreeView.cpp-857-
CTreeView.cpp:858: GB.GetFunction(&_get_settings_func, GB.FindClass("Qt"),
"_GetColumnViewSettings", "ColumnView;", "s");
CTreeView.cpp:859: GB.GetFunction(&_set_settings_func, GB.FindClass("Qt"),
"_SetColumnViewSettings", "ColumnView;s", "");
CTreeView.cpp-860-
CTreeView.cpp-861- init = true;
CTreeView.cpp-862-}
makes me think the attached patch could prevent this problem. I am not sure,
but this may have been introduced since 2.7.0.
I chose not to force QT in the ebuild. I believe gambas can be build as a
basic interpreter only, without the GUI IDE, so that it can run programs
stand-alone. I do not know if any other distribution does this, but if it is
possible, Gentoo should give the user the choice to do it.
(In reply to comment #30)
> I chose not to force QT in the ebuild. I believe gambas can be build as a
> basic interpreter only, without the GUI IDE, so that it can run programs
> stand-alone. I do not know if any other distribution does this, but if it is
> possible, Gentoo should give the user the choice to do it.
>
Maybe I am just running it wrong? I will attempt your patch at a later date and
provide feedback. thanks.
You are right. My patch in comment 29 is not correct. I am working on
something different and will obsolete it (the patch) when I have it.
If you still have the same build from comment 28, could you try this:
%% GB_GUI="gb.gtk" ./gambas2
It still may not work, but you may get a different error message. Thanks.
(In reply to comment #32)
> If you still have the same build from comment 28, could you try this:
> %% GB_GUI="gb.gtk" ./gambas2
>
> It still may not work, but you may get a different error message. Thanks.
>
Same error message actually.
Created an attachment (id=164472) [details]
gambas-2.8.2.ebuild
The IDE will not build properly without qt3. At least that is what I think
after reading more code. The new ebuild reflects this. I looked at debian a
little and how they package gambas2 for lenny. They have a gambas2-runtime and
a gambas2-ide packages. They also separate the help and examples into a
gambas2-doc package. That is why I added doc and examples to the USE flags. I
may also have to add LINGUAS support in the future, but lets get this working
first.
If you plan on removing all other versions, should gambas2 be unsloted? There
is a gambas3 on the horizon, apparently.
How will bug 163724 affect this package?
Does pkg_postrm see the USE flags the package was installed with or the current
USE flags? I was thinking about what happens during an upgrade with a USE
change and how that might affect using use conditionals in pkg_postrm.
(In reply to comment #38)
> Created an attachment (id=164472) [edit] [details]
> gambas-2.8.2.ebuild
>
> The IDE will not build properly without qt3. At least that is what I think
ok.
> after reading more code. The new ebuild reflects this. I looked at debian a
> little and how they package gambas2 for lenny. They have a gambas2-runtime and
> a gambas2-ide packages. They also separate the help and examples into a
> gambas2-doc package. That is why I added doc and examples to the USE flags.
sounds good.
I
> may also have to add LINGUAS support in the future, but lets get this working
> first.
agreed.
>
> If you plan on removing all other versions, should gambas2 be unsloted? There
> is a gambas3 on the horizon, apparently.
Well, its not trivial to just un-slot a package. You have to slotmove it so
that portage knows about it. If there is a future SLOT=3 then let's keep the
existing slot there because it doesn't hurt anything.
>
> How will bug 163724 affect this package?
maybe gambas should depend on virtual/libffi after it is unmasked? not sure
yet.
>
> Does pkg_postrm see the USE flags the package was installed with or the current
> USE flags? I was thinking about what happens during an upgrade with a USE
> change and how that might affect using use conditionals in pkg_postrm.
the ones that it was installed with, they are preserved in environment.bz2
Our patchset is getting huge for this package.
I have emailed upstream.
Could you look at gambas-2.8.0-help-path.patch, the last "+" line. I do not
understand why I have to use "ln -s" instead of "${LN_S}". ${LN_S} just does
not work for me; the symlinks are not created.
I just got an email that the majority of the patches have been accepted. On
the next version bump I will update the ebuild and only the Gentoo-specific
patches should remain.
Any ideas on why ${LN_S} does not work correctly?
(In reply to comment #41)
> I just got an email that the majority of the patches have been accepted. On
> the next version bump I will update the ebuild and only the Gentoo-specific
> patches should remain.
Great.
>
> Any ideas on why ${LN_S} does not work correctly?
>
No, not really. Problem with the sandbox or something?
I do not know if it is the sandbox. It looks like a simple relative symlink to
me. So far I suspect that ${LN_S} might be assigned something other than "ln
-s", but I do not know how to check.
I do not mind updating the patch every time there is a change, but I thought we
might want to try to fix this while waiting for the version bump.
(In reply to comment #43)
> I do not know if it is the sandbox. It looks like a simple relative symlink to
> me. So far I suspect that ${LN_S} might be assigned something other than "ln
> -s", but I do not know how to check.
>
> I do not mind updating the patch every time there is a change, but I thought we
> might want to try to fix this while waiting for the version bump.
>
2.8.2 is in CVS now, should hit your mirrors in an hour or so. Thanks for all
your work. Feel free to CC me on future gambas bugs.
