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.
On 5 April 2012 08:06, David C. Rankin drankinatty@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
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_MODULE...
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!
On 04/05/2012 09:10 AM, David C. Rankin wrote:
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_MODULE...
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!
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!
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....
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.
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
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
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?
On 04/09/2012 05:12 AM, Nix wrote:
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?
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!
-
Calvin Morrison -
David C. Rankin -
Nix