On 02/27/2012 09:56 AM, David C. Rankin wrote:
On 02/25/2012 04:39 PM, Jay wrote:
Also, the version of crystal in the tde git tree is 1.0.5 according to the documentation with it. We should build with 1.0.7.Yes, you are right. Today i replaced the configure file in current git, with the configure file from 1.0.7 source. It configures OK but the build fails at the library. Am looking through it now.
Jay
Jay, All,
I submitted: http://bugs.pearsoncomputing.net/bugzilla/show_bug.cgi?id=878
this morning to confirm/update the git tree source to 1.0.7. That way as we go though this process we can be confident we are all using the same, current source to submit patches on.
Even closer yet again! I am building version 1.0.7 from the tarball. Perhaps the brain-trust can add a few more pointers to my errors and we can finally get this one resolved. The primary issue is naming. The biggest one is when crystal is being compiled and linked, it is looking for -lkdeui when it should be looking for -ltdeui. I have created a patch to handle the kdeui -> tdeui references and I've attached it to the page (works). Now I'm down to a strange area where libtool is complaining about "unrecognized option" at the end of the build. I have no experience with this type of stuff, so if you have guidance for me -- I'll take it :)
configure.in:54: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... aclocal.m4:6218: _LT_AC_SYS_LIBPATH_AIX is expanded from... aclocal.m4:10919: AC_LIBTOOL_PROG_LD_SHLIBS is expanded from... aclocal.m4:9686: _LT_AC_LANG_GCJ_CONFIG is expanded from... aclocal.m4:9685: AC_LIBTOOL_LANG_GCJ_CONFIG is expanded from... aclocal.m4:7570: _LT_AC_TAGCONFIG is expanded from... aclocal.m4:6057: AC_LIBTOOL_SETUP is expanded from... aclocal.m4:6037: _AC_PROG_LIBTOOL is expanded from... aclocal.m4:6002: AC_PROG_LIBTOOL is expanded from... aclocal.m4:11759: AM_PROG_LIBTOOL is expanded from... aclocal.m4:3484: KDE_PROG_LIBTOOL is expanded from... configure.in:54: the top level touch ./config.h.in cd . && /bin/sh ./config.status config.h config.status: creating config.h make all-recursive make[1]: Entering directory `/build/src/crystal-1.0.7' Making all in pics make[2]: Entering directory `/build/src/crystal-1.0.7/pics' cd .. && /bin/sh ./config.status pics/Makefile depfiles config.status: creating pics/Makefile config.status: executing depfiles commands make[2]: Leaving directory `/build/src/crystal-1.0.7/pics' make[2]: Entering directory `/build/src/crystal-1.0.7/pics' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/opt/trinity/include -I/opt/qt3/include -I. -I/opt/trinity/include/tqt -DQT_THREAD_SUPPORT -D_REENTRANT -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -MT embedtool.o -MD -MP -MF ".deps/embedtool.Tpo" \ -c -o embedtool.o `test -f 'embedtool.cpp' || echo './'`embedtool.cpp; \ then mv -f ".deps/embedtool.Tpo" ".deps/embedtool.Po"; \ else rm -f ".deps/embedtool.Tpo"; exit 1; \ fi /bin/sh ../libtool --silent --mode=link --tag=CXX g++ -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu -o embedtool -L/opt/trinity/lib -L/opt/qt3/lib embedtool.o -lqt-mt -lz -lpng -lz -lm -lXext -lX11 -lSM -lICE -lpthread g++: error: unrecognized option '--sort-common' g++: error: unrecognized option '--as-needed' g++: error: unrecognized option '--hash-style=gnu' make[2]: *** [embedtool] Error 1 make[2]: Leaving directory `/build/src/crystal-1.0.7/pics' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/src/crystal-1.0.7' make: *** [all] Error 2
Is this a libtool issue? What are the following errors:
g++: error: unrecognized option '--sort-common' g++: error: unrecognized option '--as-needed' g++: error: unrecognized option '--hash-style=gnu'
More importantly -- how do I go about curing them :) Sure would be nice if a CMakeLists.txt file (and the remaining cmake files, suddenly appeared and were woking :p But, in the interim, I would simply take a few pointers to help me get over this latest issue. Thanks!