5 Apr
2012
5 Apr
'12
5:36 p.m.
All,
Beginning a complete rebuild last night was evidently a bad idea. 13 packages
that had previously built without any error now fail to build. The list of
failing packages include:
Beginning build of: libkarma - Apr 4 20:19:06
makepkg --> FAILED
Beginning build of: dependencies/python-tqt - Apr 4 20:12:56
makepkg --> FAILED
Beginning build of: libraries/kipi-plugins - Apr 4 22:43:59
makepkg --> FAILED
Beginning build of: tdegames - Apr 4 23:49:31
makepkg --> FAILED
Beginning build of: tdegraphics - Apr 5 00:21:04
makepkg --> FAILED
Beginning build of: tdepim - Apr 5 00:30:10
makepkg --> FAILED
Beginning build of: applications/rosegarden - Apr 5 00:34:51
makepkg --> FAILED
Beginning build of: applications/basket - Apr 5 00:38:14
makepkg --> FAILED
Beginning build of: applications/k3b - Apr 5 00:39:00
makepkg --> FAILED
Beginning build of: applications/gwenview - Apr 5 00:44:53
makepkg --> FAILED
Beginning build of: applications/kima - Apr 5 00:49:19
makepkg --> FAILED
Beginning build of: applications/krusader - Apr 5 00:54:10
makepkg --> FAILED
Beginning build of: tdesdk - Apr 5 00:57:28
makepkg --> FAILED
The only new packages installed that are related to the failures are:
binutils-2.22-5 boost-1.49.0-1.1 boost-libs-1.49.0-1.1 coreutils-8.16-2
expat-2.1.0-1 fftw-3.3.1-1 freetype2-2.4.9-2 gcc-4.7.0-3 gcc-libs-4.7.0-3
glibc-2.15-10 krb5-1.10.1-2 libarchive-3.0.4-1 libltdl-2.4.2-5
libtool-2.4.2-5 linux-api-headers-3.3-1 p11-kit-0.12-1 tzdata-2012b-3
xfig-3.2.5b-8 xorg-server-1.12.0.901-1 xorg-server-common-1.12.0.901-1
Of those - the obvious winners look like gcc-4.7, glibc-2.15 and xorg.
Frustrating, yes, but understanding the failures will probably disclose
weaknesses in the codebase. I'll put time into trying to narrow down what broke.
You guys that are build wizards, please let me know if you see, or know of, a
common thread that may have been pulled in with gcc 4.7 that may be the base of
the build problem.
--
David C. Rankin, J.D.,P.E.
5 Apr
5 Apr
6:47 p.m.
New subject: [trinity-devel] Massive Build Failures on Arch - 13 prior building packages FAIL
On 5 April 2012 08:06, David C. Rankin <drankinatty(a)suddenlinkmail.com> wrote:
All,
Beginning a complete rebuild last night was evidently a bad idea. 13 packages
that had previously built without any error now fail to build. The list of
failing packages include:
Beginning build of: libkarma - Apr 4 20:19:06
makepkg --> FAILED
Beginning build of: dependencies/python-tqt - Apr 4 20:12:56
makepkg --> FAILED
Beginning build of: libraries/kipi-plugins - Apr 4 22:43:59
makepkg --> FAILED
Beginning build of: tdegames - Apr 4 23:49:31
makepkg --> FAILED
Beginning build of: tdegraphics - Apr 5 00:21:04
makepkg --> FAILED
Beginning build of: tdepim - Apr 5 00:30:10
makepkg --> FAILED
Beginning build of: applications/rosegarden - Apr 5 00:34:51
makepkg --> FAILED
Beginning build of: applications/basket - Apr 5 00:38:14
makepkg --> FAILED
Beginning build of: applications/k3b - Apr 5 00:39:00
makepkg --> FAILED
Beginning build of: applications/gwenview - Apr 5 00:44:53
makepkg --> FAILED
Beginning build of: applications/kima - Apr 5 00:49:19
makepkg --> FAILED
Beginning build of: applications/krusader - Apr 5 00:54:10
makepkg --> FAILED
Beginning build of: tdesdk - Apr 5 00:57:28
makepkg --> FAILED
The only new packages installed that are related to the failures are:
binutils-2.22-5 boost-1.49.0-1.1 boost-libs-1.49.0-1.1 coreutils-8.16-2
expat-2.1.0-1 fftw-3.3.1-1 freetype2-2.4.9-2 gcc-4.7.0-3 gcc-libs-4.7.0-3
glibc-2.15-10 krb5-1.10.1-2 libarchive-3.0.4-1 libltdl-2.4.2-5
libtool-2.4.2-5 linux-api-headers-3.3-1 p11-kit-0.12-1 tzdata-2012b-3
xfig-3.2.5b-8 xorg-server-1.12.0.901-1 xorg-server-common-1.12.0.901-1
Of those - the obvious winners look like gcc-4.7, glibc-2.15 and xorg.
Frustrating, yes, but understanding the failures will probably disclose
weaknesses in the codebase. I'll put time into trying to narrow down what broke.
You guys that are build wizards, please let me know if you see, or know of, a
common thread that may have been pulled in with gcc 4.7 that may be the base of
the build problem.
--
David C. Rankin, J.D.,P.E.
http://gcc.gnu.org/gcc-4.7/changes.html
Relevant links. Also can we get some output of the failures in an
attachment or something?
Calvin
7:40 p.m.
New subject: [trinity-devel] Massive Build Failures on Arch - 13 prior building packages FAIL
On 04/05/2012 08:17 AM, Calvin Morrison wrote:
http://gcc.gnu.org/gcc-4.7/changes.html
Relevant links. Also can we get some output of the failures in an
attachment or something?
Calvin
GRRR! Nothing like almost getting things set up perfectly just to get kicked in
the balls by gcc -- again! Remember the gcc 4.5 <cstddef> fun :)
I'm collecting build failure info for each of the failures this morning and I'll
post. Currently I'm working on python-tqt. Just tried a post configure patch but
still no deal.
Calvin - what I will do is put all the failure logs up at:
http://www.3111skyline.com/dl/dt/tde/err/gcc47/
I will separate them into different directories (eg:)
http://www.3111skyline.com/dl/dt/tde/err/gcc47/python-tqt/
and then I will separate the progress I've made with patches into subdirs (eg:)
http://www.3111skyline.com/dl/dt/tde/err/gcc47/python-tqt/patched-SIP_MODUL…
I really need your help to get over this gcc hump. Between you me and pawel,
we should be able to whip this into shape fairly quickly. Thanks.
The build logs for python-tqt are there. I'm working on the others now and
should have it complete within the hour. Also I had to add -fpermissive to
tdebase and a couple of others - we will want to fix those as well.
Thanks again!
--
David C. Rankin, J.D.,P.E.
9:12 p.m.
New subject: [trinity-devel] Massive Build Failures on Arch - 13 prior building packages FAIL
On 04/05/2012 09:10 AM, David C. Rankin wrote:
On 04/05/2012 08:17 AM, Calvin Morrison wrote:
Calvin, Pawell,
I have captured build logs for all the packages failing due to gcc. Some of
the packages are failing during PACKAGING - which is strange. I have created a
compressed archive of the logs only which you can get here:
http://www.3111skyline.com/dl/dt/tde/err/gcc47/build-logs-0405.tar.xz
All of the files along with the PKGBUILD used are located under:
http://www.3111skyline.com/dl/dt/tde/err/gcc47/
The files I have are:
./kipi-plugins/tde-kipi-plugins-3.5.14_dev-2-x86_64-build.log
./kipi-plugins/PKGBUILD
./tdegraphics/PKGBUILD
./tdegraphics/tde-tdegraphics-3.5.14_dev-2-x86_64-build.log
./krusader/tde-krusader-3.5.14_dev-2-x86_64-build.log
./krusader/PKGBUILD
./rosegarden/tde-rosegarden-3.5.14_dev-2-x86_64-build.log
./rosegarden/PKGBUILD
./tdegames/PKGBUILD
./tdegames/tde-tdegames-3.5.14_dev-1-x86_64-package.log
./tdegames/tde-tdegames-3.5.14_dev-1-x86_64-build.log
./gwenview/tde-gwenview-3.5.14_dev-2-x86_64-build.log
./gwenview/PKGBUILD
./gwenview/tde-gwenview-3.5.14_dev-2-x86_64-package.log
./basket/PKGBUILD
./basket/tde-basket-1.0.3-2-x86_64-build.log
./kima/tde-kima-3.5.14_dev-2-x86_64-build.log
./kima/PKGBUILD
./k3b/PKGBUILD
./k3b/tde-k3b-3.5.14_dev-2-x86_64-build.log
./python-tqt/PKGBUILD
./python-tqt/patched-SIP_MODULE_NAME/PKGBUILD
./python-tqt/patched-SIP_MODULE_NAME/tde-python-tqt-3.5.14_dev-1-x86_64-build.log
./python-tqt/tde-python-tqt-3.5.14_dev-1-x86_64-build.log
./tdepim/tde-tdepim-3.5.14_dev-3-x86_64-build.log
./tdepim/PKGBUILD
./tdesdk/PKGBUILD
./tdesdk/tde-tdesdk-3.5.14_dev-2-x86_64-build.log
./tdesdk/tde-tdesdk-3.5.14_dev-2-x86_64-package.log
Please let me know when you guys have something to test. I need your help here
as it would take me to Christmas to fix the first one on my own. Thanks!
--
David C. Rankin, J.D.,P.E.
http://gcc.gnu.org/gcc-4.7/changes.html
Relevant links. Also can we get some output of the failures in an
attachment or something?
Calvin
GRRR! Nothing like almost getting things set up perfectly just to get kicked in
the balls by gcc -- again! Remember the gcc 4.5 <cstddef> fun :)
I'm collecting build failure info for each of the failures this morning and I'll
post. Currently I'm working on python-tqt. Just tried a post configure patch but
still no deal.
Calvin - what I will do is put all the failure logs up at:
http://www.3111skyline.com/dl/dt/tde/err/gcc47/
I will separate them into different directories (eg:)
http://www.3111skyline.com/dl/dt/tde/err/gcc47/python-tqt/
and then I will separate the progress I've made with patches into subdirs (eg:)
http://www.3111skyline.com/dl/dt/tde/err/gcc47/python-tqt/patched-SIP_MODUL…
I really need your help to get over this gcc hump. Between you me and pawel,
we should be able to whip this into shape fairly quickly. Thanks.
The build logs for python-tqt are there. I'm working on the others now and
should have it complete within the hour. Also I had to add -fpermissive to
tdebase and a couple of others - we will want to fix those as well.
Thanks again!
11:55 p.m.
New subject: [trinity-devel] Massive Build Failures on Arch - 13 prior building packages FAIL
On 04/05/2012 08:17 AM, Calvin Morrison wrote:
http://gcc.gnu.org/gcc-4.7/changes.html
Relevant links. Also can we get some output of the failures in an
attachment or something?
Calvin
Calvin,
I read that. What are you saying that we are being bitten by in there? Most of
it was Greek, but the only thing I could draw from it is that some of the new
C++11 implementation is now clashing with old code in TDE causing it to be
interpreted by the compiler as something other than what it was designed to be.
That is the only GUESS I have after reading through the information...
Continuing to GUESS, these two looked suspect:
-> G++ now sets the predefined macro __cplusplus to the correct value, 199711L
for C++98/03, and 201103L for C++11.
-> G++ now correctly implements the two-phase lookup rules such that an
unqualified name used in a template must have an appropriate declaration found
either in scope at the point of definition of the template or by
argument-dependent lookup at the point of instantiation. As a result, code that
relies on a second unqualified lookup at the point of instantiation to find
functions declared after the template or in dependent bases will be rejected.
The compiler will suggest ways to fix affected code, and using the -fpermissive
compiler flag will allow the code to compile with a warning.
template <class T>
void f() { g(T()); } // error, g(int) not found by argument-dependent lookup
void g(int) { } // fix by moving this declaration before the declaration of f
template <class T>
struct A: T {
// error, B::g(B) not found by argument-dependent lookup
void f() { g(T()); } // fix by using this->g or A::g
};
struct B { void g(B); };
int main()
{
f<int>();
A<B>().f();
}
Which would explain why I had to compile tdebase with -fpermissive for the
first time last night.
How you check for this stuff is way beyond me....
--
David C. Rankin, J.D.,P.E.
6 Apr
6 Apr
8:03 p.m.
New subject: [trinity-devel] Massive Build Failures on Arch - 13 prior building packages FAIL
On 5 Apr 2012, David C. Rankin spake thusly:
I read that. What are you saying that we are being
bitten by in there? Most of
it was Greek, but the only thing I could draw from it is that some of the new
C++11 implementation is now clashing with old code in TDE causing it to be
interpreted by the compiler as something other than what it was designed to be.
Definitely not. The C++11 stuff only applies when the appropriate -std
option is specified, which it had bloody well better not be in this case
because C++11 and C++99 have different libstdc++ ABIs (e.g. the size of
an STL list<> is different).
-> G++ now sets the predefined macro __cplusplus to
the correct value, 199711L
for C++98/03, and 201103L for C++11.
That's the same as always for C++98/03: only C++11 is different (which
couldn't be set to the right value before owing to lack of a time
machine).
-> G++ now correctly implements the two-phase
lookup rules such that an
unqualified name used in a template must have an appropriate declaration found
either in scope at the point of definition of the template or by
argument-dependent lookup at the point of instantiation.
At last!
How you check for this stuff is way beyond me....
Wait for a failure, then move the errant definition up a bit. (This may
require creating new header files here and there, I suppose.)
It's just code motion, not rewriting. Not hard.
--
NULL && (void)
8:58 p.m.
New subject: [trinity-devel] Massive Build Failures on Arch - 13 prior building packages FAIL
On 04/06/2012 09:33 AM, Nix wrote:
Wait for a failure, then move the errant definition up
a bit. (This may
require creating new header files here and there, I suppose.)
It's just code motion, not rewriting. Not hard.
That's great news! The limitation here still applies -- most of it is Greek :).
I you smart guys who understand this stuff can peek at that code and come up
with a cook-book recipe of what needs to more where and how to identify it, then
we can educate everybody on what needs to be done.
One other note, the gcc 4.7. failures seem to affect x86_64 much worse than
i686. I kicked off an i686 build last night on gcc 4.7 and it ran flawlessly
until tdegames -- but then failed with an 'install' error (see Liddell's
comment). Meaning the code built fine under gcc 4.7 up to that point, but then
failed during 'make install' due to libtool .la problems:
libtool: relink: g++ -fPIC -DPIC -shared -nostdlib
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/crtbeginS.o .libs/kolf.o .libs/game.o
.libs/canvasitem.o .libs/ball.o .libs/newgame.o .libs/config.o
.libs/scoreboard.o .libs/editor.o .libs/pluginloader.o .libs/object.o
.libs/vector.o .libs/printdialogpage.o .libs/kcomboboxdialog.o
.libs/kvolumecontrol.o .libs/floater.o .libs/slope.o -L/opt/trinity/lib
-L/opt/tqt3/lib -L/build/pkg/opt/trinity/lib -ltdegames -lkdnssd -ltdeprint
-lkio -lartskde -L/usr/lib/gcc/i686-pc-linux-gnu/4.6.3
-L/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../.. -lstdc++ -lm -lc -lgcc_s
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/crtendS.o
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../crtn.o -march=i686 -mtune=generic
-O2 -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro
-Wl,--hash-style=gnu -Wl,-soname -Wl,libkolf.so.1 -o .libs/libkolf.so.1.2.0
libtool: relink: g++ -fPIC -DPIC -shared -nostdlib
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/crtbeginS.o .libs/kolf_dummy.o
-Wl,-rpath -Wl,/opt/trinity/lib -Wl,-rpath -Wl,/opt/tqt3/lib
-L/build/src/tdegames/kolf/.libs -L/build/src/tdegames/libtdegames/.libs
-L/opt/trinity/lib -L/opt/tqt3/lib -L/build/pkg/opt/trinity/lib -ltdeinit_kolf
-lkolf -ltdegames -lkdnssd -ltdeprint -lkio -lartskde
-L/usr/lib/gcc/i686-pc-linux-gnu/4.6.3
-L/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../.. -lstdc++ -lm -lc -lgcc_s
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/crtendS.o
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../crtn.o -march=i686 -mtune=generic
-O2 -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro
-Wl,--hash-style=gnu -Wl,-soname -Wl,kolf.so -o .libs/kolf.so
/build/src/tdegames/kolf/.libs/libkolf.so: file not recognized: File truncated
collect2: ld returned 1 exit status
libtool: install: error: relink `kolf.la' with the above command before
installing it
make[3]: *** [install-tdeinitLTLIBRARIES] Error 1
make[3]: *** Waiting for unfinished jobs....
libtool: install: /bin/install -c -p .libs/libkolf.so.1.2.0T
/build/pkg/opt/trinity/lib/libkolf.so.1.2.0
libtool: install: (cd /build/pkg/opt/trinity/lib && { ln -s -f libkolf.so.1.2.0
libkolf.so.1 || { rm -f libkolf.so.1 && ln -s libkolf.so.1.2.0 libkolf.so.1; };
})
libtool: install: (cd /build/pkg/opt/trinity/lib && { ln -s -f libkolf.so.1.2.0
libkolf.so || { rm -f libkolf.so && ln -s libkolf.so.1.2.0 libkolf.so; }; })
libtool: install: /bin/install -c -p .libs/libkolf.lai
/build/pkg/opt/trinity/lib/libkolf.la
libtool: install: warning: relinking `libtdeinit_kolf.la'
libtool: install: (cd /build/src/tdegames/kolf; /bin/sh
/build/src/tdegames/libtool --tag CXX --mode=relink g++ -Wno-long-long -Wundef
-ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W
-Wpointer-arith -fno-builtin -g3 -fno-inline -march=i686 -mtune=generic -O2
-pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2
-fpermissive -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor
-fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt
-DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT
-DQT_NO_TRANSLATION -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu
-o libtdeinit_kolf.la -rpath /opt/trinity/lib -no-undefined -avoid-version
-L/opt/trinity/lib -L/opt/tqt3/lib main.lo libkolf.la -inst-prefix-dir /build/pkg)
libtool: relink: g++ -fPIC -DPIC -shared -nostdlib
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/crtbeginS.o .libs/main.o
-L/build/src/tdegames/libtdegames/.libs -L/opt/trinity/lib -L/opt/tqt3/lib
-L/build/pkg/opt/trinity/lib -lkolf -ltdegames -lkdnssd -ltdeprint -lkio
-lartskde -L/usr/lib/gcc/i686-pc-linux-gnu/4.6.3
-L/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../.. -lstdc++ -lm -lc -lgcc_s
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/crtendS.o
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../crtn.o -march=i686 -mtune=generic
-O2 -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro
-Wl,--hash-style=gnu -Wl,-soname -Wl,libtdeinit_kolf.so -o
.libs/libtdeinit_kolf.so
libtool: install: /bin/install -c -p .libs/libtdeinit_kolf.soT
/build/pkg/opt/trinity/lib/libtdeinit_kolf.so
libtool: install: /bin/install -c -p .libs/libtdeinit_kolf.lai
/build/pkg/opt/trinity/lib/libtdeinit_kolf.la
libtool: install: warning: remember to run `libtool --finish /opt/trinity/lib'
make[3]: Leaving directory `/build/src/tdegames/kolf'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/build/src/tdegames/kolf'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/build/src/tdegames/kolf'
make: *** [install-recursive] Error 1
--
David C. Rankin, J.D.,P.E.
8:59 p.m.
New subject: [trinity-devel] Massive Build Failures on Arch - 13 prior building packages FAIL
Disregard,
I note the i686 box did not update to gcc 4.7, but was still on 4.6.3 - No
Wonder it built so well :)
On 04/06/2012 10:28 AM, David C. Rankin wrote:
One other note, the gcc 4.7. failures seem to affect
x86_64 much worse than
i686. I kicked off an i686 build last night on gcc 4.7 and it ran flawlessly
until tdegames -- but then failed with an 'install' error (see Liddell's
comment). Meaning the code built fine under gcc 4.7 up to that point, but then
failed during 'make install' due to libtool .la problems:
libtool: relink: g++ -fPIC -DPIC -shared -nostdlib
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/crtbeginS.o .libs/kolf.o .libs/game.o
.libs/canvasitem.o .libs/ball.o .libs/newgame.o .libs/config.o
.libs/scoreboard.o .libs/editor.o .libs/pluginloader.o .libs/object.o
.libs/vector.o .libs/printdialogpage.o .libs/kcomboboxdialog.o
.libs/kvolumecontrol.o .libs/floater.o .libs/slope.o -L/opt/trinity/lib
-L/opt/tqt3/lib -L/build/pkg/opt/trinity/lib -ltdegames -lkdnssd -ltdeprint
-lkio -lartskde -L/usr/lib/gcc/i686-pc-linux-gnu/4.6.3
-L/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../.. -lstdc++ -lm -lc -lgcc_s
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/crtendS.o
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../crtn.o -march=i686 -mtune=generic
-O2 -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro
-Wl,--hash-style=gnu -Wl,-soname -Wl,libkolf.so.1 -o .libs/libkolf.so.1.2.0
libtool: relink: g++ -fPIC -DPIC -shared -nostdlib
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/crtbeginS.o .libs/kolf_dummy.o
-Wl,-rpath -Wl,/opt/trinity/lib -Wl,-rpath -Wl,/opt/tqt3/lib
-L/build/src/tdegames/kolf/.libs -L/build/src/tdegames/libtdegames/.libs
-L/opt/trinity/lib -L/opt/tqt3/lib -L/build/pkg/opt/trinity/lib -ltdeinit_kolf
-lkolf -ltdegames -lkdnssd -ltdeprint -lkio -lartskde
-L/usr/lib/gcc/i686-pc-linux-gnu/4.6.3
-L/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../.. -lstdc++ -lm -lc -lgcc_s
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/crtendS.o
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../crtn.o -march=i686 -mtune=generic
-O2 -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro
-Wl,--hash-style=gnu -Wl,-soname -Wl,kolf.so -o .libs/kolf.so
/build/src/tdegames/kolf/.libs/libkolf.so: file not recognized: File truncated
collect2: ld returned 1 exit status
libtool: install: error: relink `kolf.la' with the above command before
installing it
make[3]: *** [install-tdeinitLTLIBRARIES] Error 1
make[3]: *** Waiting for unfinished jobs....
libtool: install: /bin/install -c -p .libs/libkolf.so.1.2.0T
/build/pkg/opt/trinity/lib/libkolf.so.1.2.0
libtool: install: (cd /build/pkg/opt/trinity/lib && { ln -s -f libkolf.so.1.2.0
libkolf.so.1 || { rm -f libkolf.so.1 && ln -s libkolf.so.1.2.0 libkolf.so.1; };
})
libtool: install: (cd /build/pkg/opt/trinity/lib && { ln -s -f libkolf.so.1.2.0
libkolf.so || { rm -f libkolf.so && ln -s libkolf.so.1.2.0 libkolf.so; }; })
libtool: install: /bin/install -c -p .libs/libkolf.lai
/build/pkg/opt/trinity/lib/libkolf.la
libtool: install: warning: relinking `libtdeinit_kolf.la'
libtool: install: (cd /build/src/tdegames/kolf; /bin/sh
/build/src/tdegames/libtool --tag CXX --mode=relink g++ -Wno-long-long -Wundef
-ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W
-Wpointer-arith -fno-builtin -g3 -fno-inline -march=i686 -mtune=generic -O2
-pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2
-fpermissive -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor
-fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt
-DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT
-DQT_NO_TRANSLATION -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu
-o libtdeinit_kolf.la -rpath /opt/trinity/lib -no-undefined -avoid-version
-L/opt/trinity/lib -L/opt/tqt3/lib main.lo libkolf.la -inst-prefix-dir /build/pkg)
libtool: relink: g++ -fPIC -DPIC -shared -nostdlib
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/crtbeginS.o .libs/main.o
-L/build/src/tdegames/libtdegames/.libs -L/opt/trinity/lib -L/opt/tqt3/lib
-L/build/pkg/opt/trinity/lib -lkolf -ltdegames -lkdnssd -ltdeprint -lkio
-lartskde -L/usr/lib/gcc/i686-pc-linux-gnu/4.6.3
-L/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../.. -lstdc++ -lm -lc -lgcc_s
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/crtendS.o
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../crtn.o -march=i686 -mtune=generic
-O2 -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro
-Wl,--hash-style=gnu -Wl,-soname -Wl,libtdeinit_kolf.so -o
.libs/libtdeinit_kolf.so
libtool: install: /bin/install -c -p .libs/libtdeinit_kolf.soT
/build/pkg/opt/trinity/lib/libtdeinit_kolf.so
libtool: install: /bin/install -c -p .libs/libtdeinit_kolf.lai
/build/pkg/opt/trinity/lib/libtdeinit_kolf.la
libtool: install: warning: remember to run `libtool --finish /opt/trinity/lib'
make[3]: Leaving directory `/build/src/tdegames/kolf'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/build/src/tdegames/kolf'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/build/src/tdegames/kolf'
make: *** [install-recursive] Error 1
--
David C. Rankin, J.D.,P.E.
9 Apr
9 Apr
3:42 p.m.
New subject: [trinity-devel] Massive Build Failures on Arch - 13 prior building packages FAIL
On 6 Apr 2012, David C. Rankin spake thusly:
/build/src/tdegames/kolf/.libs/libkolf.so: file not
recognized: File truncated
collect2: ld returned 1 exit status
libtool: install: error: relink `kolf.la' with the above command before
installing it
make[3]: *** [install-tdeinitLTLIBRARIES] Error 1
make[3]: *** Waiting for unfinished jobs....
That's not a GCC 4.7 error, that's an installation problem. It looks
like you're doing 'make install' in parallel. KDE 3.5.x at least did not
support that, and I thought Trinity didn't either. Is this not true
after cmakeification?
--
NULL && (void)
7:37 p.m.
New subject: [trinity-devel] Massive Build Failures on Arch - 13 prior building packages FAIL
On 04/09/2012 05:12 AM, Nix wrote:
On 6 Apr 2012, David C. Rankin spake thusly:
Nix,
You are correct! I got it solved this morning (see the Arch list). It was a
parallel build problem. Setting:
make -j1 DESTDIR="$pkgdir/" install
during the package() phase seems to have solved the relink error. It seems
that parallel building during package WAS the culprit. The build of
tdegames went fine after adding -j1.
Strange that prior to the last update of autoconf, I could build tde with
'MAKEFLAGS="-j${CPUCORES}"' in makepkg.conf. I don't know what
changed, but it
certainly impacted the ability to 'install' with the -j flag set for parallel
builds.
Thanks Nix!
--
David C. Rankin, J.D.,P.E.
/build/src/tdegames/kolf/.libs/libkolf.so: file
not recognized: File truncated
collect2: ld returned 1 exit status
libtool: install: error: relink `kolf.la' with the above command before
installing it
make[3]: *** [install-tdeinitLTLIBRARIES] Error 1
make[3]: *** Waiting for unfinished jobs....
That's not a GCC 4.7 error, that's an installation problem. It looks
like you're doing 'make install' in parallel. KDE 3.5.x at least did not
support that, and I thought Trinity didn't either. Is this not true
after cmakeification?
4461
days inactive
4465
days old
9 comments
3 participants
participants (3)
-
Calvin Morrison -
David C. Rankin -
Nix