SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Slackware (personalized Window Maker), Mint (customized MATE)
Posts: 1,309
Rep:
Gosh! There is a bunch of incredible patient people here. I am sure that I could learn a lot from all of you about the patience. Unfortunately I doubt I would like to learn that at all. Anyway I really admire you, guys!
Time and time again we have seen GCC becoming more compliant with the C/C++ standards and as it does old code stops compiling.
This does not mean the binaries are no longer compatible.
Naturally about the case of newer GCCs. Yeah that's one thing, but still a rare matter. Also I'm implying about the dependencies which could break the build, not the compiler.
Alright I get the significance of it, yet again I don't think not-too-old codes would always break from it.
Also, if you take a look at some of the SlackBuilds, I think the packages you mention that may not compile with newer GCCs are already filtered in my script.
Last edited by konsolebox; 04-22-2013 at 12:32 AM.
@T3slider So everything you said is also about my post which is:
Quote:
Of course there would be exceptions that the package would still work even
after the dependencies were upgraded/downgraded, but still it would be better
that it was verified, and one of it is through building the source with what
is currently there. We could check the consistency of dynamic linking with
libraries as well of course, but sometimes it's also about other depended
stuffs not just libraries
?
Well I guess that's already your choice if you want to assume compatibility of binaries and not verify/take risks in that case.
Though it could be verified as one by checking the consistency of dynamic linking within binaries, both executables and libraries like how it's done in revdep-rebuild of Gentoo.
Well I guess an expert could already tell.
Last edited by konsolebox; 04-22-2013 at 12:42 AM.
Its not easy to count how many cycles something is going to be on modern Intel hardware...
That's what I can't be bothered to do. Unless I perceive an obvious increase in speed, I've wasted my time rebuilding something. And, it needs to be a speed increase in an area that has been slowing *me* down. Better numbers from a benchmark aren't, by themselves, much of a payoff for me.
Obviously, I'm not big on optimizing. It's been a long time since I've seen a reason to play with it.
I hope you'd be patient as that would take time. It's not something we have to rush. Also, I already mentioned earlier that if a package won't compile with new added march parameter then that package could just remain unoptimized.
Well, I'll be patient and wait for report on which ones will have to remain unoptimized (or which need fixed SlackBuilds). Like most people, I would consider this to be your next meaningful contribution to the thread.
Quote:
Of course there would be exceptions that the package would still work even after the dependencies were upgraded/downgraded,
They're not the exception. This "exception" is the entire reason why Slackware works so well without a dependency-tracking package manager. It is therefore one of the foundations of Slackware's design.
Not all optimizations used by various CPUs actually mesh well with all software.
Case in point is the GCC flag -O3.
-O3 is a high level optimization flag for software compiling which means the math used with be very strict during the CPU calculations of the software processing phase. However, this does pose a danger. Because the math is VERY strict compared to -O2, or even -O1, any mishandling of the process can result in unstable software and frequent crashes.
The same goes for various iX86, and even AMD64/EM64T CPUs.
Slackware attempts to run the software with compatibility for the lowest possible 32-bit CPU core the Pentium (i486) processor, or the lowest possible 64-bit Athlon64/Pentium4 (x86-64) processors. By doing this, the software is able to function in various ranges of hardware opening the door to Compatibility being a key feature. The same goes for the x86-64 series of processors. If you've ever watched a program compile for x64 CPUs, they all use the -fPIC flag rather than a -i386, -i686, -nocona, etc. flag.
Fewer specific optimizations lead to better compatibility, less problems with unstable code, and less chance for non-compliant optimizations to break the code and possibly prevent other packages from working correctly.
If you want a heavily optimized system... Go to Gentoo. Gentoo is built to YOUR PC specifications. The same goes for Linux From Scratch.
These were the summary for the errors that occurred.
Code:
--------- aspell.SlackBuild.custom ----------
depbase=`echo common/cache.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I./gen -I./gen -I./common -I./interfaces/cc/ -I./modules/speller/default/ -DLOCALEDIR="/usr/share/locale" -march=core2 -O2 -fPIC -fno-exceptions -MT common/cache.lo -MD -MP -MF $depbase.Tpo -c -o common/cache.lo common/cache.cpp &&\
mv -f $depbase.Tpo $depbase.Plo
In file included from ./common/config.hpp:14:0,
from modules/filter/tex.cpp:8:
./common/vector.hpp: In instantiation of 'void acommon::Vector<T>::append(const T*, unsigned int) [with T = acommon::FilterChar]':
./common/filter_char_vector.hpp:35:31: required from here
./common/vector.hpp:27:7: error: 'insert' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]In file included from ./common/filter_char_vector.hpp:10:0,
from ./common/convert.hpp:14,
from modules/filter/email.cpp:10:
./common/vector.hpp: In instantiation of 'void acommon::Vector<T>::append(const T*, unsigned int) [with T = acommon::FilterChar]':
./common/filter_char_vector.hpp:35:31: required from here
./common/vector.hpp:27:7: error: 'insert' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
./common/vector.hpp:27:7: note: declarations in dependent base 'std::vector<acommon::FilterChar, std::allocator<acommon::FilterChar> >' are not found by unqualified lookup./common/vector.hpp:27:7: note: declarations in dependent base 'std::vector<acommon::FilterChar, std::allocator<acommon::FilterChar> >' are not found by unqualified lookup
./common/vector.hpp:27:7: note: use 'this->insert' instead
./common/vector.hpp:27:7: note: use 'this->insert' instead
In file included from ./common/config.hpp:14:0,
from modules/filter/nroff.cpp:24:
./common/vector.hpp: In instantiation of 'void acommon::Vector<T>::append(const T*, unsigned int) [with T = acommon::FilterChar]':
./common/filter_char_vector.hpp:35:31: required from here
./common/vector.hpp:27:7: error: 'insert' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
./common/vector.hpp:27:7: note: declarations in dependent base 'std::vector<acommon::FilterChar, std::allocator<acommon::FilterChar> >' are not found by unqualified lookup
./common/vector.hpp:27:7: note: use 'this->insert' instead
In file included from ./common/config.hpp:14:0,
from modules/filter/sgml.cpp:27:
./common/vector.hpp: In instantiation of 'void acommon::Vector<T>::append(const T*, unsigned int) [with T = acommon::FilterChar]':
./common/filter_char_vector.hpp:35:31: required from here
./common/vector.hpp:27:7: error: 'insert' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
./common/vector.hpp:27:7: note: declarations in dependent base 'std::vector<acommon::FilterChar, std::allocator<acommon::FilterChar> >' are not found by unqualified lookup
./common/vector.hpp:27:7: note: use 'this->insert' instead
--------- cvs.SlackBuild.custom ----------
gcc -DHAVE_CONFIG_H -I. -I.. -I../src -march=core2 -O2 -fPIC -MT getline.o -MD -MP -MF .deps/getline.Tpo -c -o getline.o getline.c
In file included from getline.c:25:0:
getline.h:15:3: error: conflicting types for 'getline'
In file included from getline.c:22:0:
/usr/include/stdio.h:675:20: note: previous declaration of 'getline' was here
getline.c:158:1: error: conflicting types for 'getline'
In file included from getline.c:22:0:
/usr/include/stdio.h:675:20: note: previous declaration of 'getline' was here
--------- dev86.SlackBuild.custom ----------
make[5]: Entering directory `/tmp/dev86-0.16.17/libc/bcc'
make[5]: *** No rule to make target `__ldivmod.o)', needed by `/tmp/dev86-0.16.17/libc/libc.a'. Stop.
--------- dirmngr.SlackBuild.custom ----------
make[2]: Entering directory `/tmp/dirmngr-1.1.0/src'
x86_64-slackware-linux-gcc -I../jnlib -I/usr/include -march=core2 -O2 -fPIC -Wall -Wno-pointer-sign -o dirmngr dirmngr.o server.o crlcache.o crlfetch.o ldapserver.o certcache.o b64dec.o cdblib.o ldap.o http.o misc.o ocsp.o estream.o estream-printf.o validate.o exechelp.o get-path.o ../jnlib/libjnlib.a -lassuan -L/usr/lib64 -lgpg-error -L/usr/lib64 -lgcrypt -lgpg-error -L/usr/lib64 -lksba -lgpg-error -L/usr/lib64 -lpth -ldl -lnsl
x86_64-slackware-linux-gcc -march=core2 -O2 -fPIC -Wall -Wno-pointer-sign -o dirmngr_ldap dirmngr_ldap-dirmngr_ldap.o dirmngr_ldap-no-libgcrypt.o ../jnlib/libjnlib.a -L/usr/lib64 -lgpg-error -lldap
/usr/lib64/gcc/x86_64-slackware-linux/4.7.1/../../../../x86_64-slackware-linux/bin/ld: dirmngr_ldap-dirmngr_ldap.o: undefined reference to symbol 'ber_free'
/usr/lib64/gcc/x86_64-slackware-linux/4.7.1/../../../../x86_64-slackware-linux/bin/ld: note: 'ber_free' is defined in DSO /usr/lib64/liblber-2.4.so.2 so try adding it to the linker command line
/usr/lib64/liblber-2.4.so.2: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
--------- expect.SlackBuild.custom ----------
ERROR: no /tmp/tcl8.5.8 -- this is needed for Tcl internal headers
--------- fuse.SlackBuild.custom ----------
Making all in util
make[1]: Entering directory `/tmp/fuse-2.8.5/util'
gcc -DHAVE_CONFIG_H -I. -I../include -I../lib -march=core2 -O2 -fPIC -MT fusermount-fusermount.o -MD -MP -MF .deps/fusermount-fusermount.Tpo -c -o fusermount-fusermount.o `test -f 'fusermount.c' || echo './'`fusermount.c
fusermount.c: In function 'clone_newns':
fusermount.c:295:44: error: 'CLONE_NEWNS' undeclared (first use in this function)
fusermount.c:295:44: note: each undeclared identifier is reported only once for each function it appears in
--------- gpm.SlackBuild.custom ----------
x86_64-slackware-linux-gcc -I/tmp/gpm-1.20.1/src -DHAVE_CONFIG_H -include headers/config.h -Wall -DSYSCONFDIR="\"/etc\"" -DSBINDIR="\"/usr/sbin\"" -march=core2 -O2 -fPIC -c -o client.o client.c
client.c: In function 'accept_client_connection':
client.c:132:36: warning: passing argument 3 of 'accept' from incompatible pointer type [enabled by default]
In file included from client.c:36:0:
/usr/include/sys/socket.h:214:12: note: expected 'socklen_t * __restrict__' but argument is of type 'size_t *'
client.c:170:20: error: storage size of 'sucred' isn't known
client.c:171:34: error: invalid application of 'sizeof' to incomplete type 'struct ucred'
client.c:170:20: warning: unused variable 'sucred' [-Wunused-variable]
--------- guile.SlackBuild.custom ----------
make[3]: Entering directory `/tmp/guile-1.8.8/libguile'
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.. -I.. -I.. -pthread -march=core2 -O2 -fPIC -Wall -Wmissing-prototypes -Werror -MT libguile_la-async.lo -MD -MP -MF .deps/libguile_la-async.Tpo -c -o libguile_la-async.lo `test -f 'async.c' || echo './'`async.c
libtool: compile: gcc -DHAVE_CONFIG_H -I.. -I.. -I.. -pthread -march=core2 -O2 -fPIC -Wall -Wmissing-prototypes -Werror -MT libguile_la-async.lo -MD -MP -MF .deps/libguile_la-async.Tpo -c async.c -fPIC -DPIC -o .libs/libguile_la-async.o
async.c: In function 'scm_i_queue_async_cell':
async.c:243:14: error: variable 'count' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
make[3]: *** [libguile_la-async.lo] Error 1
--------- libkarma.SlackBuild.custom ----------
make[1]: Entering directory `/tmp/libkarma-0.1.1/tools'
cc -I../src -ltag_c -lz -L ../lib -Wall -pedantic riocp.c -o riocp pathedit.o -lkarma
/usr/lib64/libtag.so.1: undefined reference to `std::string::resize(unsigned long, char)'
/usr/lib64/libtag.so.1: undefined reference to `std::ostream& std::ostream::_M_insert<unsigned long>(unsigned long)'
/usr/lib64/libtag.so.1: undefined reference to `std::ctype<char>::_M_widen_init() const'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::erase(__gnu_cxx::__normal_iterator<wchar_t*, std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >, __gnu_cxx::__normal_iterator<wchar_t*, std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >)'
/usr/lib64/gcc/x86_64-slackware-linux/4.7.1/../../../../lib64/libtag_c.so: undefined reference to `operator delete(void*)'
/usr/lib64/libtag.so.1: undefined reference to `std::_Rb_tree_decrement(std::_Rb_tree_node_base*)'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::reserve(unsigned long)'
/usr/lib64/libtag.so.1: undefined reference to `operator new[](unsigned long)'
/usr/lib64/libtag.so.1: undefined reference to `std::_Rb_tree_increment(std::_Rb_tree_node_base*)'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::append(wchar_t const*, unsigned long)'
/usr/lib64/libtag.so.1: undefined reference to `__cxa_end_catch'
/usr/lib64/libtag.so.1: undefined reference to `std::_Rb_tree_increment(std::_Rb_tree_node_base const*)'
/usr/lib64/libtag.so.1: undefined reference to `std::cout'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_M_leak_hard()'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_Rep::_S_empty_rep_storage'
/usr/lib64/libtag.so.1: undefined reference to `__cxa_guard_release'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::rfind(wchar_t const*, unsigned long, unsigned long) const'
/usr/lib64/libtag.so.1: undefined reference to `std::string::_M_leak_hard()'
/usr/lib64/libtag.so.1: undefined reference to `std::ostream::flush()'
/usr/lib64/libtag.so.1: undefined reference to `std::__throw_out_of_range(char const*)'
/usr/lib64/gcc/x86_64-slackware-linux/4.7.1/../../../../lib64/libtag_c.so: undefined reference to `std::ios_base::Init::~Init()'
/usr/lib64/libtag.so.1: undefined reference to `std::ostream::put(char)'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)'
/usr/lib64/libtag.so.1: undefined reference to `__cxa_pure_virtual'
/usr/lib64/libtag.so.1: undefined reference to `__dynamic_cast'
/usr/lib64/libtag.so.1: undefined reference to `std::__throw_bad_cast()'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()'
/usr/lib64/libtag.so.1: undefined reference to `std::cerr'
/usr/lib64/libtag.so.1: undefined reference to `std::string::assign(char const*, unsigned long)'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string(wchar_t const*, std::allocator<wchar_t> const&)'
/usr/lib64/libtag.so.1: undefined reference to `std::__detail::_List_node_base::_M_unhook()'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&)'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::append(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&)'
/usr/lib64/libtag.so.1: undefined reference to `operator delete[](void*)'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, unsigned long, unsigned long)'
/usr/lib64/gcc/x86_64-slackware-linux/4.7.1/../../../../lib64/libtag_c.so: undefined reference to `__gxx_personality_v0'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_ios<char, std::char_traits<char> >::clear(std::_Ios_Iostate)'
/usr/lib64/libtag.so.1: undefined reference to `std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*, std::_Rb_tree_node_base&)'
/usr/lib64/libtag.so.1: undefined reference to `__cxa_begin_catch'
/usr/lib64/libtag.so.1: undefined reference to `__cxa_rethrow'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::resize(unsigned long, wchar_t)'
/usr/lib64/gcc/x86_64-slackware-linux/4.7.1/../../../../lib64/libtag_c.so: undefined reference to `std::ios_base::Init::Init()'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_Rep::_S_create(unsigned long, unsigned long, std::allocator<wchar_t> const&)'
/usr/lib64/libtag.so.1: undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
/usr/lib64/libtag.so.1: undefined reference to `std::ostream& std::ostream::_M_insert<bool>(bool)'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::find(wchar_t const*, unsigned long, unsigned long) const'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_Rep::_M_destroy(std::allocator<wchar_t> const&)'
/usr/lib64/libtag.so.1: undefined reference to `std::string::_Rep::_M_destroy(std::allocator<char> const&)'
/usr/lib64/gcc/x86_64-slackware-linux/4.7.1/../../../../lib64/libtag_c.so: undefined reference to `operator new(unsigned long)'
/usr/lib64/libtag.so.1: undefined reference to `std::__detail::_List_node_base::_M_transfer(std::__detail::_List_node_base*, std::__detail::_List_node_base*)'
/usr/lib64/libtag.so.1: undefined reference to `std::_Rb_tree_decrement(std::_Rb_tree_node_base const*)'
/usr/lib64/libtag.so.1: undefined reference to `std::string::_Rep::_S_empty_rep_storage'
/usr/lib64/libtag.so.1: undefined reference to `__cxa_guard_abort'
/usr/lib64/gcc/x86_64-slackware-linux/4.7.1/../../../../lib64/libtag_c.so: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
/usr/lib64/libtag.so.1: undefined reference to `std::__throw_length_error(char const*)'
/usr/lib64/gcc/x86_64-slackware-linux/4.7.1/../../../../lib64/libtag_c.so: undefined reference to `vtable for __cxxabiv1::__class_type_info'
/usr/lib64/libtag.so.1: undefined reference to `std::ostream::operator<<(int)'
/usr/lib64/libtag.so.1: undefined reference to `std::terminate()'
/usr/lib64/libtag.so.1: undefined reference to `std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&)'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_string()'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::assign(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&)'
/usr/lib64/libtag.so.1: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long)'
/usr/lib64/libtag.so.1: undefined reference to `__cxa_guard_acquire'
collect2: error: ld returned 1 exit status
make[1]: *** [riocp] Error 1
make[1]: Leaving directory `/tmp/libkarma-0.1.1/tools'
make: *** [tools] Error 2
--------- libmad.SlackBuild.custom ----------
gcc: error: unrecognized command line option '-fforce-mem'gcc: error: unrecognized command line option '-fforce-mem'
--------- obexftp.SlackBuild.custom ----------
Making all in ruby
make[3]: Entering directory `/tmp/obexftp-0.23/swig/ruby'
PREFIX=/usr /usr/bin/ruby extconf.rb --with-obexftp-include=../..
/usr/lib64/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- auto_gem (LoadError)
from /usr/lib64/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
--------- p2c.SlackBuild.custom ----------
cc -march=core2 -O2 -fPIC makeproto.c -o makeproto
makeproto.c: In function 'usage':
makeproto.c:137:5: warning: incompatible implicit declaration of built-in function 'exit' [enabled by default]
makeproto.c: In function 'main':
makeproto.c:210:13: warning: incompatible implicit declaration of built-in function 'exit' [enabled by default]
makeproto.c:501:9: warning: incompatible implicit declaration of built-in function 'exit' [enabled by default]
./makeproto -n -m -h -t16 -a35 -s1 -i trans.c stuff.c out.c comment.c lex.c parse.c decl.c expr.c pexpr.c funcs.c dir.c hpmods.c citmods.c -o p2c.proto
./makeproto -n -m -h -t16 -a35 -s0 -x trans.c stuff.c out.c comment.c lex.c parse.c decl.c expr.c pexpr.c funcs.c dir.c hpmods.c citmods.c -o p2c.hdrs
cc -c -march=core2 -O2 -fPIC -DHASDUMPS -DP2C_HOME=\"/usr/lib64/p2c\" trans.c
In file included from trans.c:23:0:
trans.h:88:0: warning: "strcmp" redefined [enabled by default]
In file included from /usr/include/string.h:637:0,
from trans.h:81,
from trans.c:23:
/usr/include/bits/string2.h:800:0: note: this is the location of the previous definition
In file included from trans.c:23:0:
trans.h:1776:42: warning: built-in function 'logf' declared as non-function [enabled by default]
In file included from trans.h:1856:0,
from trans.c:23:
p2c.hdrs:172:17: error: conflicting types for 'getline'
In file included from trans.h:39:0,
from trans.c:23:
/usr/include/stdio.h:675:20: note: previous declaration of 'getline' was here
trans.c: In function 'main':
trans.c:782:3: warning: overflow in implicit constant conversion [-Woverflow]
make: *** [trans.o] Error 1
--------- qca.SlackBuild.custom ----------
g++ -c -m64 -pipe -g -O2 -Wall -W -D_REENTRANT -fPIC -DDATADIR=\"/usr/share/qca\" -DQCA_SYSTEMSTORE_PATH=\"/etc/ssl/certs/ca-certificates.crt\" -DBOTAN_TYPES_QT -DBOTAN_TOOLS_ONLY -DBOTAN_FIX_GDB -DBOTAN_MINIMAL_BIGINT -DBOTAN_MP_WORD_BITS=32 -DBOTAN_KARAT_MUL_THRESHOLD=12 -DBOTAN_KARAT_SQR_THRESHOLD=12 -DBOTAN_EXT_MUTEX_QT -DBOTAN_EXT_ALLOC_MMAP -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_SHARED -I/usr/lib64/qt/mkspecs/linux-g++-64 -I. -I/usr/lib64/qt/include/QtCore -I/usr/lib64/qt/include -I../include/QtCrypto -I. -Ibotantools/botan -I. -o big_ops3.o botantools/botan/big_ops3.cpp
In file included from botantools/botan/botan/bigint.h:38:0,
from botantools/botan/big_ops2.cpp:34:
botantools/botan/botan/secmem.h: In instantiation of 'QCA::Botan::SecureVector<T>::SecureVector(const T*, QCA::Botan::u32bit) [with T = unsigned int; QCA::Botan::u32bit = unsigned int]':
botantools/botan/big_ops2.cpp:170:40: required from here
botantools/botan/botan/secmem.h:217:41: error: 'set' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
botantools/botan/botan/secmem.h:217:41: note: declarations in dependent base 'QCA::Botan::MemoryRegion<unsigned int>' are not found by unqualified lookup
botantools/botan/botan/secmem.h:217:41: note: use 'this->set' instead
--------- scim-bridge.SlackBuild.custom ----------
g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../common -DSCIM_LOCALEDIR=\"@SCIM_LOCALEDIR@\" -DSCIM_ICONDIR=\"/usr/share/scim/icons\" -DSCIM_KEYBOARD_ICON_FILE=\"/usr/share/scim/icons/keyboard.png\" -DSCIM_LIBEXECDIR=\"/usr/lib64/scim-1.0\" -DSCIM_VERSION=\"1.4.6\" -DGETTEXT_PACKAGE=\"@GETTEXT_PACKAGE@\" -I/usr/include/scim-1.0 -march=core2 -O2 -fPIC -MT scim_bridge-scim-bridge-agent-panel-client.o -MD -MP -MF .deps/scim_bridge-scim-bridge-agent-panel-client.Tpo -c -o scim_bridge-scim-bridge-agent-panel-client.o `test -f 'utils/scim-bridge-agent-panel-client.cpp' || echo './'`utils/scim-bridge-agent-panel-client.cpp
scim-bridge-agent-signal-listener.cpp: In function 'void static_finalize()':
scim-bridge-agent-signal-listener.cpp:73:39: error: 'close' was not declared in this scope
scim-bridge-agent-signal-listener.cpp:74:37: error: 'close' was not declared in this scope
make[2]: *** [scim_bridge-scim-bridge-agent-signal-listener.o] Error 1
make[2]: Entering directory `/tmp/scim-bridge-0.4.16/agent'
g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../common -DSCIM_LOCALEDIR=\"@SCIM_LOCALEDIR@\" -DSCIM_ICONDIR=\"/usr/share/scim/icons\" -DSCIM_KEYBOARD_ICON_FILE=\"/usr/share/scim/icons/keyboard.png\" -DSCIM_LIBEXECDIR=\"/usr/lib64/scim-1.0\" -DSCIM_VERSION=\"1.4.6\" -DGETTEXT_PACKAGE=\"@GETTEXT_PACKAGE@\" -I/usr/include/scim-1.0 -march=core2 -O2 -fPIC -MT scim_bridge-scim-bridge-agent-signal-listener.o -MD -MP -MF .deps/scim_bridge-scim-bridge-agent-signal-listener.Tpo -c -o scim_bridge-scim-bridge-agent-signal-listener.o `test -f 'scim-bridge-agent-signal-listener.cpp' || echo './'`scim-bridge-agent-signal-listener.cpp
scim-bridge-agent-signal-listener.cpp: In function 'void static_finalize()':
scim-bridge-agent-signal-listener.cpp:73:39: error: 'close' was not declared in this scope
scim-bridge-agent-signal-listener.cpp:74:37: error: 'close' was not declared in this scope
make[2]: *** [scim_bridge-scim-bridge-agent-signal-listener.o] Error 1
--------- svgalib.SlackBuild.custom ----------
cc -Wall -Wstrict-prototypes -fomit-frame-pointer -O2 -fno-strength-reduce -pipe -I../include -L../sharedlib -s -o gtfcalc -DTESTING_GTF gtf/gtfcalc.c -lvga -lm
gtf/gtfcalc.c:67:15: error: static declaration of 'round' follows non-static declaration
make[1]: *** [gtfcalc] Error 1
make[1]: Leaving directory `/tmp/svgalib-1.9.25/utils'
make: *** [textutils] Error 2
--------- tix.SlackBuild.custom ----------
checking for Tcl private include files... configure: error: Cannot find private header tclInt.h in /tmp/tcl8.5.11
--------- vbetool.SlackBuild.custom ----------
make: *** No rule to make target `/usr/lib/libpci.a', needed by `vbetool'. Stop.
--------- xchat.SlackBuild.custom ----------
make[5]: Entering directory `/tmp/xchat-2.8.8/src/common/dbus'
depbase=`echo dbus-client.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -DHAVE_CONFIG_H -I. -I../../.. -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -march=core2 -O2 -fPIC -Wall -pipe -g -Wno-pointer-sign -funsigned-char -MT dbus-client.o -MD -MP -MF $depbase.Tpo -c -o dbus-client.o dbus-client.c &&\
mv -f $depbase.Tpo $depbase.Po
In file included from ../xchat.h:3:0,
from dbus-client.c:24:
/usr/include/glib-2.0/glib/gslist.h:28:2: error: #error "Only <glib.h> can be included directly."
In file included from ../xchat.h:4:0,
from dbus-client.c:24:
/usr/include/glib-2.0/glib/glist.h:28:2: error: #error "Only <glib.h> can be included directly."
In file included from ../xchat.h:5:0,
from dbus-client.c:24:
/usr/include/glib-2.0/glib/gutils.h:28:2: error: #error "Only <glib.h> can be included directly."
In file included from ../xchat.h:6:0,
from dbus-client.c:24:
/usr/include/glib-2.0/glib/giochannel.h:28:2: error: #error "Only <glib.h> can be included directly."
In file included from ../xchat.h:7:0,
from dbus-client.c:24:
/usr/include/glib-2.0/glib/gstrfuncs.h:28:2: error: #error "Only <glib.h> can be included directly."
--------- xpaint.SlackBuild.custom ----------
gcc -O2 -fno-strength-reduce -fno-strict-aliasing -I/usr/include -Dlinux -D__amd64__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO -DERRORBEEP -DFEATURE_FRACTAL -DXAW3D -DXAW3DG -I/usr/include/X11 -I/usr/include/freetype2 "-DEDITOR=\"emacs -fn 9x15 -cr green -ms red -bg lightyellow -fg black\"" "-DSHAREDIR=\"/usr/share/xpaint\"" "-DXAPPLOADDIR=\"/usr/lib64/X11/app-defaults\"" "-DXPAINT_VERSION=\"2.8.16\"" "-DLPCCMD=\"/usr/sbin/lpc status\"" -DERRORBEEP -DFEATURE_FRACTAL -c -o help.o help.c
graphic.c:170:8: error: variable 'ImgProcessInfo' has initializer but incomplete type
gcc -O2 -fno-strength-reduce -fno-strict-aliasing -I/usr/include -Dlinux -D__amd64__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO -DERRORBEEP -DFEATURE_FRACTAL -DXAW3D -DXAW3DG -I/usr/include/X11 -I/usr/include/freetype2 "-DEDITOR=\"emacs -fn 9x15 -cr green -ms red -bg lightyellow -fg black\"" "-DSHAREDIR=\"/usr/share/xpaint\"" "-DXAPPLOADDIR=\"/usr/lib64/X11/app-defaults\"" "-DXPAINT_VERSION=\"2.8.16\"" "-DLPCCMD=\"/usr/sbin/lpc status\"" -DERRORBEEP -DFEATURE_FRACTAL -c -o graphic.o graphic.c
graphic.c:170:8: error: variable 'ImgProcessInfo' has initializer but incomplete type
So among those errors shown are we sure that all of them doesn't show signs of runtime inconsistencies? And I so thought that Slackware was designed to be as stable as possible. And one would say those are just rough numbers? Are we redefining Slackware now because of that. Isn't Slackware meant to be as stable as possible? If that would be the case the Slackware would give exemptions then it's no longer any different to other distros that make milestone releases.
I tried to compile the normal SlackBuilds but none of them build as well.
Some packages happened to be detected as failed if they send output packages to a directory other than /tmp. I used another script to rescan the logs to check which one has actually built properly.
Code:
#!/bin/bash
BUILD_LOGS_DIR=./build-logs
LOG_FILE="$0.log.gz"
LOG_FILE_SUMMARY="$0.summary.log"
[[ BASH_VERSINFO -ge 4 ]] || {
echo "You need Bash version 4.0 or newer to run this script."
exit 1
}
shopt -s extglob || {
echo "Unable to enable extglob."
exit 1
}
shopt -s nullglob || {
echo "Unable to enable extglob."
exit 1
}
function getabspath {
local -a T1 T2
local -i I=0
local IFS=/ A
case "$1" in
/*)
read -r -a T1 <<< "$1"
;;
*)
read -r -a T1 <<< "/$PWD/$1"
;;
esac
T2=()
for A in "${T1[@]}"; do
case "$A" in
..)
[[ I -ne 0 ]] && unset T2\[--I\]
continue
;;
.|'')
continue
;;
esac
T2[I++]=$A
done
case "$1" in
*/)
[[ I -ne 0 ]] && __="/${T2[*]}/" || __=/
;;
*)
[[ I -ne 0 ]] && __="/${T2[*]}" || __=/.
;;
esac
}
function log {
echo "$1"
echo "$1" >&4
}
function log_action {
echo -n "$1... "
echo -n "$1... " >&4
}
function log_result {
echo "$1."
echo "$1." >&4
}
function log_open {
exec > >(exec tee >(exec gzip -c >> "$LOG_FILE")) && exec 4>> "$LOG_FILE_SUMMARY"
}
function log_close {
exec 4>&-
}
function main {
getabspath "$BUILD_LOGS_DIR"
BUILD_LOGS_DIR_ABS=$__
log_open || {
echo "Failed to open LOG_FILE_SUMMARY \"$LOG_FILE_SUMMARY\" for writing."
return 1
}
log "----------------------------------------"
log "Checking started: $(date '+%F %T')"
while read -u 8 -r FILE; do
DIR=${FILE%%/+([^/])}
BASE=${FILE##*/}
PACKAGE=${BASE%.SlackBuild.custom}
BUILD_LOG_FILE=$BUILD_LOGS_DIR_ABS/$BASE.log.gz
log_action "Examining $FILE with $BUILD_LOG_FILE"
if [[ -e $BUILD_LOG_FILE ]] && zcat "$BUILD_LOG_FILE" | grep 'Slackware package .* created.' &>/dev/null; then
log "Package was built successfully."
else
log_result "Package failed to build."
fi
rm -fr "/tmp/${PACKAGE}-"* "/tmp/package-$PACKAGE"
done 8< <(exec find -type f -name '*.SlackBuild.custom' | sort -t / -k 2,2)
log "Checking finished: $(date '+%F %T')"
log "----------------------------------------"
log_close
return 0
}
main "$@"
I also modified the build script but I haven't used it yet.
As for KDE I chose not to build it yet and I'm not sure if I still would as I see that it's no longer needed. Experienced compilers could tell how a simple arch flag could not give much difference to how a compilation of a package could be done. And the numbers are more than enough.
Last edited by konsolebox; 05-03-2013 at 11:16 PM.
Not all optimizations used by various CPUs actually mesh well with all software.
Not all but generally it does.
Quote:
Case in point is the GCC flag -O3.
-O3 is a high level optimization flag for software compiling which means the math used with be very strict during the CPU calculations of the software processing phase. However, this does pose a danger. Because the math is VERY strict compared to -O2, or even -O1, any mishandling of the process can result in unstable software and frequent crashes.
According to the gcc manual:
Code:
-O3 Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning,
-fgcse-after-reload, -ftree-vectorize and -fipa-cp-clone options.
What part there relates to math?
Quote:
The same goes for various iX86, and even AMD64/EM64T CPUs.
Like what variation of an output?
Quote:
Slackware attempts to run the software with compatibility for the lowest possible 32-bit CPU core the Pentium (i486) processor, or the lowest possible 64-bit Athlon64/Pentium4 (x86-64) processors. By doing this, the software is able to function in various ranges of hardware opening the door to Compatibility being a key feature. The same goes for the x86-64 series of processors. If you've ever watched a program compile for x64 CPUs, they all use the -fPIC flag rather than a -i386, -i686, -nocona, etc. flag.
Fewer specific optimizations lead to better compatibility, less problems with unstable code, and less chance for non-compliant optimizations to break the code and possibly prevent other packages from working correctly.
Wasn't it already obvious that I was asking for less-compatible more system-optimized distros?
Quote:
If you want a heavily optimized system... Go to Gentoo. Gentoo is built to YOUR PC specifications. The same goes for Linux From Scratch.
I'm using Gentoo and Gentoo gives its purpose, but Gentoo needs to be compiled, and Slackware is more suitable for quick static installations, and is more stable as it seems.
konsolebox your output from libkarma is a perfect example of gcc becoming more strict with it's rules.
If you patch libkarma's Makefile to include libstdc++ in the linker parameters then it works just fine. The giveaway with that one is all the "std::*" related output which comes back to the c++ standard requiring the std namespace to be explicitly declared, gcc was not always compliant with that.
Other errors you have there are also similar but relate to c headers that must now be explicitly included, you also have one that is turning warnings into errors (unused variables are not real errors)
Please also note that these source code errors have nothing to do with the resultant binary code output by the compiler, they are from the pre-processor side.
I applaud your effort and I am impressed with the number of packages that do compile. However, the ones that don't (and the ones that were deemed not to be compiled/optimized) are the sticking points and in order to make sure that this effort continues, mass builds like yours would have to be done frequently to identify any packages that stop compiling (and if it gets to a scenario in which patching the existing, stable version to compile is too great a task, and newer versions of that package are less stable or buggy, but the existing binary build still works just fine...then I'm not really sure how to proceed except to keep what works, which means keeping an uncompilable package).
Quote:
Originally Posted by konsolebox
So among those errors shown are we sure that all of them doesn't show signs of runtime inconsistencies? And I so thought that Slackware was designed to be as stable as possible. And one would say those are just rough numbers? Are we redefining Slackware now because of that. Isn't Slackware meant to be as stable as possible? If that would be the case the Slackware would give exemptions then it's no longer any different to other distros that make milestone releases.
I really think you need to forget everything you think you know about binary compatibility, because it seems that despite multiple people trying to tell you that binaries often do remain compatible despite sources not compiling, you refuse to believe it. Run xchat and you will see that it runs just fine, and is as stable as can be expected. You will get no benefit by recompiling it (which can't be done at he moment without patching/upgrading). In the case of xchat, for example, the glib upgrade changed the way headers can be included, requiring dependent applications to tweak their glib include lines. Other than this change for compilation purposes, glib remains quite compatible from a binary perspective, so there is absolutely no reason for the previously built binary package to be unstable despite its sources not being able to compile without tweaking them. Of course, it is a very, very easy fix to get it to compile in this case, but it illustrates the point well. And as wildwizard pointed out, libkarma fails to compile because gcc requires explicit inclusion of libstdc++ whereas previous versions of gcc included it automatically despite it not being explicit. Again, the old binary is not any less compatible or stable -- it is just a matter of the newer gcc being more strict with the sources it will compile.
I will repeat myself I guess. In order for a project like this to be sustainable, each package will have to be rebuilt many times during -current's development to make sure everything can be compiled, with failing packages being patched each round. Since Pat is the only one with commit access to the SlackBuilds (as far as I know), all SlackBuild changes would have to go through him, and updating SlackBuilds for maintaining compilability without actually improving anything is wasted time. As it stands, Slackware does not recompile for each release. For your project to be reasonable, it would have to recompile for each release. I don't know where you want the man-power to come from.
konsolebox your output from libkarma is a perfect example of gcc becoming more strict with it's rules.
If you patch libkarma's Makefile to include libstdc++ in the linker parameters then it works just fine. The giveaway with that one is all the "std::*" related output which comes back to the c++ standard requiring the std namespace to be explicitly declared, gcc was not always compliant with that.
Other errors you have there are also similar but relate to c headers that must now be explicitly included, you also have one that is turning warnings into errors (unused variables are not real errors)
Yes I already know about those stuffs about new gcc restrictions and syntax incompatibilities, and other things that could make building of old software no longer work, yet what I'm saying are those that aren't about it, like possible changes within the headers of the library or other dependencies.
Quote:
Please also note that these source code errors have nothing to do with the resultant binary code output by the compiler, they are from the pre-processor side.
You sure not even change in data/structures within headers? Those that may affect function calls, and data to be used.
I applaud your effort and I am impressed with the number of packages that do compile.
Sure and I never expected those to convince you, no matter how many things of what you said would go proven wrong.
Quote:
However, the ones that don't (and the ones that were deemed not to be compiled/optimized) are the sticking points
You serious? How are those packages even comparable to gcc, glibc, mesa libraries, x libraries, core utilities, etc.
Quote:
and in order to make sure that this effort continues, mass builds like yours would have to be done frequently to identify any packages that stop compiling
Perhaps you mean they -should- be done regardless if they are being optimized or not just to verify that -those- packages are truly compatible not only by the output binary but also of the used configurations and proper functions that possible could have been changed.
It's actually because you believe changing a CFLAG for a subarchitecture would cause an error if the package is able to build as a normal x86_64, but as proven it's not. If something does not compile, it just simply not compile even if you just the normal flags (just without the march). And that you also believe that those errors found are -always- (as it seems it's what you believe) not signs of the old binary not being truly compatible (but only see it with macro-analysis through runtime; as long as you see it's working it's working and don't really bother with the difference, or probably just wait until you actually saw that one of its functionality is no longer working the way it should be) with the new versions of its dependencies. It really sounds that you only assume superiority as the way you speak but don't really have much idea how mass packages could be possibly worked out to compile. And even if you really don't care, I guess you still couldn't estimate how possibly it could really cause troubles if they are to be built with new flags. At least please try to prove your conjectures in a more technical manner. Can you give an explanation how at least 1 out of 10 packages could not cause errors, unexpected functionality, or exceptions in some of its functions if one of the packages it depends upon has already changed and that the old sources no longer compiles with it, and I mean not just because of new compilers, linkers, etc.
Quote:
(and if it gets to a scenario in which patching the existing, stable version to compile is too great a task, and newer versions of that package are less stable or buggy, but the existing binary build still works just fine...then I'm not really sure how to proceed except to keep what works, which means keeping an uncompilable package).
Well I guess you do believe that as long as you see it works, it works, and let's wait for someone to notice that it doesn't.
Quote:
I really think you need to forget everything you think you know about binary compatibility, because it seems that despite multiple people trying to tell you that binaries often do remain compatible despite sources not compiling, you refuse to believe it.
Give me a technical reason why, at least on the level of dissimilar headers which could contain settings applied in built libraries which are then still used by the old binary, which could now be different from the previous one.
Quote:
Run xchat and you will see that it runs just fine, and is as stable as can be expected. You will get no benefit by recompiling it (which can't be done at he moment without patching/upgrading). In the case of xchat, for example, the glib upgrade changed the way headers can be included, requiring dependent applications to tweak their glib include lines. Other than this change for compilation purposes, glib remains quite compatible from a binary perspective, so there is absolutely no reason for the previously built binary package to be unstable despite its sources not being able to compile without tweaking them. Of course, it is a very, very easy fix to get it to compile in this case, but it illustrates the point well. And as wildwizard pointed out, libkarma fails to compile because gcc requires explicit inclusion of libstdc++ whereas previous versions of gcc included it automatically despite it not being explicit. Again, the old binary is not any less compatible or stable -- it is just a matter of the newer gcc being more strict with the sources it will compile.
Like I said it truly is valid if the cause of it is just gcc, but again, what if the contents of the headers are already changed?
Quote:
I will repeat myself I guess. In order for a project like this to be sustainable, each package will have to be rebuilt many times during -current's development to make sure everything can be compiled, with failing packages being patched each round. Since Pat is the only one with commit access to the SlackBuilds (as far as I know), all SlackBuild changes would have to go through him, and updating SlackBuilds for maintaining compilability without actually improving anything is wasted time. As it stands, Slackware does not recompile for each release. For your project to be reasonable, it would have to recompile for each release. I don't know where you want the man-power to come from.
You could be valid if you first really prove that changes in headers could really only cause errors in building and not in runtime. Take note not only about the possible changes in constant values, but also in structures of structs or classes, which could be completely revised, or extended, and some could be not really noticeable in the main functions but on the less commonly used ones, you'll never know.
And it's not only even the headers that make changes. There are many other things that could affect runtime.
I notice that you always say this is what it is because it is; this is what others say. Now please try to prove it on a technical side this time. Give me some material basis of it - besides those obvious like new gcc restrictions and syntax causing build time errors. We actually talk about compatibility with those in the old binary and those in the new dependencies.
Last edited by konsolebox; 05-04-2013 at 01:19 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
