Packages that depend on libpthread fail to compile on amd64 after freebsd-update upgrade from 6.x to 7.x - was: Installing packages using ports after freebsd-update doesn't work on amd64
Sorin Panca wrote: Doug Barton wrote: Sorin Panca wrote: Prior to starting the upgrade I did a pkg_delete -a. I wanted a clean system (just like a reinstallation). How do I ensure that all packages were removed by pkg_delete -a ? Check /usr/local and make sure there is nothing there. In particular make sure that /usr/local/lib/compat/pkg does not exist. It sounds like this is already true, but also make sure that /var/db/pkg is empty as well. If none of that works then you've got a bigger problem. If you still can't install ruby and/or portupgrade, try installing a simple port just using 'make clean ; make install' in the port's directory. If that works, try a more complex port until something fails. If nothing fails installing manually it's a problem with portupgrade and/or ruby and you can send in a new bug report focusing on that. You might also consider using portmaster of course. :) hope this helps, Doug /usr/local/compat/pkg existed but I followed your advice and removed it. /var/db/pkg was empty when I checked it. I proceeded to trying to install /usr/ports/lang/ruby18 by make clean and then make install clean. It failed with the same error as in my previous attempts. However, some packages built correctly: shells/bash, lang/perl5.8, sysutils/ezjail and www/apache. I really wanted to take portmaster into consideration (it's a better alternative to portupgrade in my opinion also), but sysutils/puppet uses portupgrade as its backend and I use puppet on my servers. So I'm stuck with portupgrade. I also noticed when compiling other programs, that the line contains the following arguments: -fPIC -DPIC, while compiling ruby18, it only contains -fPIC. I added -DPIC to /etc/make.conf, so that the CFLAGS line would look like: CFLAGS?= -O2 -fPIC -DPIC -pipe After that, the compiler output lines still look like: cc -O2 -fno-strict-aliasing -pipe -fPIC -DRUBY_EXPORT -I. -I. -c variable.c and fails as in my previous attempts. Sorin. New data: All packages that depend on /usr/lib/libpthread.a fail to compile on FreeBSD-7.x-RELEASE after binary upgrading from FreeBSD-6.x-RELEASE The error is: /usr/bin/ld: /usr/lib/libpthread.a(thr_concurrency.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /usr/lib/libpthread.a: could not read symbols: Bad value Among those packages are: lang/ruby18, lang/python25, net/openldap24-client and devel/glib12 Sorin. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Installing packages using ports after freebsd-update doesn't work on amd64
Massimo Fusaro wrote: 2009/1/26 Sorin Panca sorin.pa...@psrk.com: Tore Lund wrote: Sorin Panca wrote: Prior to starting the upgrade I did a pkg_delete -a. I wanted a clean system (just like a reinstallation). How do I ensure that all packages were removed by pkg_delete -a ? I cannot help wonder why you try to do a binary update. Saving some configuration files and doing a reinstall might have been easier IMO. I'm located in Europe, while the server is in the US. I also think that a serious OS should be upgradable both from source and binaries without booting it from other media, at runtime. Asking people near that server to do something I should be able to do is never a good option. Regards, Sorin. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org Please remove the directory /var/db/ports/ruby and stick to default CFLAGS by removing all CFLAGS definitions from /etc/make.conf (you can add your options later) It seems that ruby always uses -pthread even if threading is not enabled, -fPIC in NOT needed. Check that libpthread.* is a symlink to libthr.* and that libthr.so - /lib/libthr.so.3 The libthr symlinks are as you described them. (As I said in my latest post, I think that not only ruby is affected by this 'bug', but all ports that try to link against libpthread. I installed ruby using pkg_add, but I continue to experiment with python. Using make config, I selected THREADING and deselected IPV6.) I commented out the CFLAGS line in /etc/make.conf, then: # cd /usr/ports/lang/python25 # rm -rf /var/db/ports/python25 # make clean === Cleaning for python25-2.5.2_3 # make install clean [...] cc -c -fno-strict-aliasing -DNDEBUG -O2 -fno-strict-aliasing -pipe -D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x2 -I. -IInclude -I./../Include -fPIC -DPy_BUILD_CORE -DSVNVERSION=\`LC_ALL=C echo exported`\ -o Modules/getbuildinfo.o ./../Modules/getbuildinfo.c if test libpython2.5.so != libpython2.5.so; then cc -shared -pthread -Wl,-hlibpython2.5.so -o libpython2.5.so Modules/_typesmodule.o Modules/getbuildinfo.o Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Parser/myreadline.o Parser/tokenizer.o Objects/abstract.o Objects/boolobject.o Objects/bufferobject.o Objects/cellobject.o Objects/classobject.o Objects/cobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/intobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/methodobject.o Objects/moduleobject.o Objects/object.o Objects/obmalloc.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/stringobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/weakrefobject.o Objects/unicodeobject.o Objects/unicodectype.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/bltinmodule.o Python/ceval.o Python/compile.o Python/codecs.o Python/errors.o Python/frozen.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getmtime.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/import.o Python/importdl.o Python/marshal.o Python/modsupport.o Python/mystrtoul.o Python/mysnprintf.o Python/pyarena.o Python/pyfpe.o Python/pystate.o Python/pythonrun.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/traceback.o Python/getopt.o Python/pystrtod.o Python/dynload_shlib.oPython/thread.o Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o Modules/threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/pwdmodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/zipimport.o Modules/symtablemodule.o Modules/xxsubtype.o -lutil -lm; ln -f libpython2.5.so libpython2.5.so; else cc -shared -pthread -o libpython2.5.so Modules/_typesmodule.o Modules/getbuildinfo.o Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.oParser/grammar.o Parser/pgen.o Parser/myreadline.o Parser/tokenizer.o Objects/abstract.o Objects/boolobject.o Objects/bufferobject.o Objects/cellobject.o Objects/classobject.o Objects/cobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/intobject.o Objects/iterobject.o
Re: Failure building apache22 and mysql51
Roland Smith wrote: On Wed, Jul 16, 2008 at 11:20:13PM +0100, Chris Rees wrote: 2008/7/14 Sorin P�nca [EMAIL PROTECTED]: I'm sorry for my late response, I was on vacation. I think this was the case (although I thought we have only amd64 machines). Is there a way to recover from this situation by ssh access only? Thank you! Sorin. Chris Rees wrote: Date: Mon, 23 Jun 2008 18:43:04 +0300 From: Sorin P?nca [EMAIL PROTECTED] Hello people! I recently upgraded a amd64 machine from FreeBSD-6.2-RELEASE-p11 to FreeBSD-7.0-RELEASE-p2 using the tutorial found at http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html All went well with the base system. I don't want to patronise, but are you sure you were running FreeBSD/amd64-6.2 before? Looks kinda like you've tried to upgrade from 6.2/i386 to 7.0/amd64. In case you have, you can't do that. Check you haven't disabled and processor-specific extensions in your BIOS, like SSE, that would also create problems if you have optimised your ports. Chris I thought devel/linuxthreads was using some old library so I tried to rebuild it: # cd ../../devel/linuxthreads make install clean # portupgrade -f wouldn't do anything === linuxthreads-2.2.3_23 is only for i386, while you are running amd64. *** Error code 1 Stop in /usr/ports/devel/linuxthreads. Any ideas what to do next? Thank you! Sorin. If I understand you correctly, you want to revert to FreeBSD/i386; in which case I'd advise that you are *extremely* careful, and make sure that everything important is recompiled in i386; FreeBSD/amd64 can run binaries from FreeBSD/i386, but not vice-versa. I *think* that you should be ok running a source update (csup sources, make buildworld installworld kernel) with arch as i386, then reboot, pkg_delete -f portupgrade\*, pkg_add -r portupgrade, portupgrade -faP etc Installworld is supposed to be done after a reboot, in this case (cross-build) you'll have a 32-bit kernel stuck with a 64-bit userland. That won't work. If you do the installworld before the reboot with a cross-buils, it will be the other way around. I'm not sure if the installworld will even complete; every system binary that is replaced will be of the wrong architecture. Don't take my word for it, it is beyond my expertise, I've deliberately made it obtuse; get someone with more knowledge to elucidate :P If you have a spare partition, you could install the new kernel and userland there, and then switch partitions. If that's not an option, make backups of your data and re-install with the i386 version. It's quicker and probably less painfull. :) For changing architectures you'll also have to remove all ports/packages and re-compile/install them for the new architecture. But you should do that anyway when going from 6.x to 7. Roland Actually I want to run on amd64 architecture on that system (let's call it system0). And recently I had a similar system running FreeBSD-6.2 (amd64 - I'm sure about this one; let's call it system1) and tried to upgrade it to FreeBSD-7.0. To my surprise I had the same errors with missing PIC flag for libpthread. While for system0 I was able to fix the issue by installing devel/pth and symlinking the binary in proper locations, I experimented a little with system1 until I rendered it unusable. My question now is: what happend to the second system? Why did the upgrade fail on this one? Unfortunatly I had to reinstall it ASAP using a FreeBSD CD, because system1 is a production system and I really can't investigate further. I still have other four systems waiting to be upgraded from 6.1 or 6.2 to 7.0 or 7.1 and even they are production, they are replaceable. So I might have the chance to experiment on them, if you think this issue should be chased down. Sorin. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Failure building apache22 and mysql51
I'm sorry for my late response, I was on vacation. I think this was the case (although I thought we have only amd64 machines). Is there a way to recover from this situation by ssh access only? Thank you! Sorin. Chris Rees wrote: Date: Mon, 23 Jun 2008 18:43:04 +0300 From: Sorin P?nca [EMAIL PROTECTED] Hello people! I recently upgraded a amd64 machine from FreeBSD-6.2-RELEASE-p11 to FreeBSD-7.0-RELEASE-p2 using the tutorial found at http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html All went well with the base system. I don't want to patronise, but are you sure you were running FreeBSD/amd64-6.2 before? Looks kinda like you've tried to upgrade from 6.2/i386 to 7.0/amd64. In case you have, you can't do that. Check you haven't disabled and processor-specific extensions in your BIOS, like SSE, that would also create problems if you have optimised your ports. Chris I thought devel/linuxthreads was using some old library so I tried to rebuild it: # cd ../../devel/linuxthreads make install clean # portupgrade -f wouldn't do anything === linuxthreads-2.2.3_23 is only for i386, while you are running amd64. *** Error code 1 Stop in /usr/ports/devel/linuxthreads. Any ideas what to do next? Thank you! Sorin. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Failure building apache22 and mysql51
Hello people! I recently upgraded a amd64 machine from FreeBSD-6.2-RELEASE-p11 to FreeBSD-7.0-RELEASE-p2 using the tutorial found at http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html All went well with the base system. Now with the ports... mysql51-server was installed and I noticed it fails to start (I mean it dies within a few seconds after the restart). First I tried doing portupgrade -af for a couple of times but after compiling everything, I'm still unlucky. Then I tried portupgrade -aPPR, also to no avail. Then: # cd /usr/ports/databases/mysql51-server # portupgrade -f --- Reinstalling 'mysql-server-5.1.25' (databases/mysql51-server) --- Building '/usr/ports/databases/mysql51-server' === Cleaning for mysql-server-5.1.25 === Vulnerability check disabled, database not found You may use the following build options: WITH_CHARSET=charsetDefine the primary built-in charset (latin1). WITH_XCHARSET=list Define other built-in charsets (may be 'all'). WITH_COLLATION=collate Define default collation (latin1_swedish_ci). WITH_OPENSSL=yesEnable secure connections. WITH_LINUXTHREADS=yes Use the linuxthreads pthread library. WITH_PROC_SCOPE_PTH=yes Use process scope threads (try it if you use libpthread). BUILD_OPTIMIZED=yes Enable compiler optimizations (use it if you need speed). BUILD_STATIC=yesBuild a static version of mysqld. (use it if you need even more speed). WITH_NDB=yesEnable support for NDB Cluster. === Extracting for mysql-server-5.1.25 = MD5 Checksum OK for mysql-5.1.25-rc.tar.gz. = SHA256 Checksum OK for mysql-5.1.25-rc.tar.gz. [ ... ] (cd .libs rm -f libndb.la ln -s ../libndb.la libndb.la) if /usr/local/bin/libtool --preserve-dup-deps --tag=CC --mode=compile cc -DMYSQL_SERVER -DDEFAULT_MYSQL_HOME=\/usr/local\ -DDATADIR=\/var/db/mysql\ -DSHAREDIR=\/usr/local/share/mysql\ -DPLUGINDIR=\/usr/local/lib/mysql/plugin\ -DHAVE_EVENT_SCHEDULER -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -I../regex -I. -O2 -fno-strict-aliasing -pipe -MT udf_example.lo -MD -MP -MF .deps/udf_example.Tpo -c -o udf_example.lo udf_example.c; \ then mv -f .deps/udf_example.Tpo .deps/udf_example.Plo; else rm -f .deps/udf_example.Tpo; exit 1; fi cc -DMYSQL_SERVER -DDEFAULT_MYSQL_HOME=\/usr/local\ -DDATADIR=\/var/db/mysql\ -DSHAREDIR=\/usr/local/share/mysql\ -DPLUGINDIR=\/usr/local/lib/mysql/plugin\ -DHAVE_EVENT_SCHEDULER -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -I../regex -I. -O2 -fno-strict-aliasing -pipe -MT udf_example.lo -MD -MP -MF .deps/udf_example.Tpo -c udf_example.c -fPIC -DPIC -o .libs/udf_example.o cc -DMYSQL_SERVER -DDEFAULT_MYSQL_HOME=\/usr/local\ -DDATADIR=\/var/db/mysql\ -DSHAREDIR=\/usr/local/share/mysql\ -DPLUGINDIR=\/usr/local/lib/mysql/plugin\ -DHAVE_EVENT_SCHEDULER -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -I../regex -I. -O2 -fno-strict-aliasing -pipe -MT udf_example.lo -MD -MP -MF .deps/udf_example.Tpo -c udf_example.c -o udf_example.o /dev/null 21 /usr/local/bin/libtool --preserve-dup-deps --tag=CC --mode=link cc -O2 -fno-strict-aliasing -pipe -o udf_example.la -module -rpath /usr/local/lib/mysql udf_example.lo -pthread -lcrypt -lm -pthread cc -shared .libs/udf_example.o -pthread -lcrypt -lm -pthread -pthread -pthread -pthread -pthread -pthread -pthread -Wl,-soname -Wl,udf_example.so.0 -o .libs/udf_example.so.0 /usr/bin/ld: /usr/lib/libpthread.a(thr_mutex.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /usr/lib/libpthread.a: could not read symbols: Bad value gmake[3]: *** [udf_example.la] Error 1 gmake[3]: Leaving directory `/usr/ports/databases/mysql51-server/work/mysql-5.1.25-rc/sql' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/databases/mysql51-server/work/mysql-5.1.25-rc/sql' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/ports/databases/mysql51-server/work/mysql-5.1.25-rc/sql' gmake: *** [all-recursive] Error 1 *** Error code 2 Stop in /usr/ports/databases/mysql51-server. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade.94200.0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=mysql-server-5.1.25 UPGRADE_PORT_VER=5.1.25 make ** Fix the problem and try again. ** Listing the failed packages (-:ignored / *:skipped / !:failed) ! databases/mysql51-server (mysql-server-5.1.25)(new compiler error) and again, with portupgrade -N www/apache22 this time: [ ... ] /bin/sh /usr/ports/www/apache22/work/httpd-2.2.8/srclib/apr/libtool --silent --mode=compile cc -O2 -fno-strict-aliasing -pipe -I/usr/local/include/mysql -DHAVE_MYSQL_H -I/usr/include -DHAVE_CONFIG_H -I./include
Re: Failure building apache22 and mysql51
Jeremy Chadwick wrote: On Mon, Jun 23, 2008 at 06:43:04PM +0300, Sorin P�nca wrote: Hello people! I recently upgraded a amd64 machine from FreeBSD-6.2-RELEASE-p11 to FreeBSD-7.0-RELEASE-p2 using the tutorial found at http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html All went well with the base system. I'm doubting that greatly. Well... they compiled successfully twice (once by doing portupgrade -a, and once by doing portupgrade -af - there were some complaines about some perl modules that we installed by cpan) and then a portupgrade -aPPR finished successfully... Anyway, how do I check everything is clean and working or how do I recompile the pthread part (library) of the system to ensure it's linked against the proper libraries? Both ports you're trying to build rely on pthread, and both die in the same way: /usr/bin/ld: /usr/lib/libpthread.a(thr_mutex.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /usr/lib/libpthread.a: could not read symbols: Bad value /usr/bin/ld: /usr/lib/libpthread.a(thr_syscalls.o): relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC /usr/lib/libpthread.a: could not read symbols: Bad value I agree. That's why I posted both of them. Is my question good or bad? I'm not a programmer, so I really try hard to understand what is happening... Sorin. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
