Re: Sylpheed doesn't compile on amd64
Hi, Torfinn Ingolfsen wrote: /usr/bin/ld: /usr/local/lib/libonig.a(regposix.o): relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libonig.a: could not read symbols: Bad value It looks more like a devel/oniguruma* problem. I've tried to compile sylpheed2 while having oniguruma5 installed and it worked. So I suggest you deinstall oniguruma or try reinstalling it first. -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Sylpheed doesn't compile on amd64
Hi, On Sun, Aug 30, 2009 at 9:11 AM, Oliver Lehmann oli...@freebsd.org wrote: It looks more like a devel/oniguruma* problem. I've tried to compile sylpheed2 while having oniguruma5 installed and it worked. So I suggest you deinstall oniguruma or try reinstalling it first. First i tried 'portupgrade -f' on oniguruma, the a portupgrade of sylpheed. But it failed again. The I did pkg_deinstall oniguruma-2.5.8 followed by portupgrade -R sylpheed and the compile of sylpheed failed again: cc -shared .libs/account.o .libs/base64.o .libs/codeconv.o .libs/customheader.o .libs/displayheader.o .libs/filter.o .libs/folder.o .libs/html.o .libs/imap.o .libs/mbox.o .libs/md5.o .libs/md5_hmac.o .libs/mh.o .libs/news.o .libs/nntp.o .libs/pop.o .libs/prefs.o .libs/prefs_account.o .libs/prefs_common.o .libs/procheader.o .libs/procmime.o .libs/procmsg.o .libs/quoted-printable.o .libs/recv.o .libs/session.o .libs/smtp.o .libs/socket.o .libs/ssl.o .libs/stringtable.o .libs/sylmain.o .libs/unmime.o .libs/utils.o .libs/uuencode.o .libs/virtual.o .libs/xml.o .libs/syl-marshal.o -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib -L/usr/local/lib -lcompface -lssl -lcrypto /usr/local/lib/libgtkspell.so /usr/local/lib/ libgtk-x11-2.0.so /usr/local/lib/libgdk-x11-2.0.so /usr/local/lib/ libatk-1.0.so /usr/local/lib/libgdk_pixbuf-2.0.so /usr/local/lib/ libpangocairo-1.0.so /usr/local/lib/libgio-2.0.so /usr/local/lib/libXext.so /usr/local/lib/libXrender.so /usr/local/lib/libXinerama.so /usr/local/lib/libXi.so /usr/local/lib/libXrandr.so /usr/local/lib/libXcursor.so /usr/local/lib/libXcomposite.so /usr/local/lib/libXdamage.so /usr/local/lib/libpangoft2-1.0.so/usr/local/lib/libXfixes.so /usr/local/lib/libcairo.so /usr/local/lib/libX11.so /usr/local/lib/libpango-1.0.so -lm /usr/local/lib/libfreetype.so /usr/local/lib/libfontconfig.so /usr/local/lib/libgobject-2.0.so /usr/local/lib/libgmodule-2.0.so/usr/local/lib/ libglib-2.0.so /usr/local/lib/libaspell.so -lonig -Wl,--export-dynamic -pthread -pthread -Wl,-rpath -Wl,/usr/local/lib -Wl,-soname -Wl,libsylph-0.so.0 -o .libs/libsylph-0.so.0 /usr/bin/ld: /usr/local/lib/libonig.a(regposix.o): relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libonig.a: could not read symbols: Bad value gmake[3]: *** [libsylph-0.la] Error 1 gmake[3]: Leaving directory `/usr/ports/mail/sylpheed2/work/sylpheed-2.7.1/libsylph' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/ports/mail/sylpheed2/work/sylpheed-2.7.1/libsylph' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/mail/sylpheed2/work/sylpheed-2.7.1' gmake: *** [all] Error 2 *** Error code 1 Stop in /usr/ports/mail/sylpheed2. *** Error code 1 Stop in /usr/ports/mail/sylpheed2. More suggestions? -- Regards, Torfinn Ingolfsen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Sylpheed doesn't compile on amd64
Hi, Torfinn Ingolfsen wrote: pkg_deinstall oniguruma-2.5.8 followed by portupgrade -R sylpheed /usr/bin/ld: /usr/local/lib/libonig.a(regposix.o): relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libonig.a: could not read symbols: Bad value So I wonder why there is still a /usr/local/lib/libonig.a when oniguruma is deinstalled? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Sylpheed doesn't compile on amd64
So I wonder why there is still a /usr/local/lib/libonig.a when oniguruma is deinstalled? ??? Probably because after deinstalling oniguruma, he tried to install sylpheed2 WITH_ONIGURUMA, so oniguruma was placed in sylpheed2's BUILD_DEPENDS, meaning that oniguruma was rebuilt and reinstalled as part of the sylpheed2 build. This is a non-default option, so it doesn't receive as much testing, and something may well be broken. Try rebuilding and reinstalling first oniguruma and then sylpheed2 with CFLAGS+=-fPIC, as the error message indicates. You may need to tinker with the linker flags as well. If that doesn't work, try removing oniguruma and then installing one of the later versions of oniguruma that uses shared libraries, as Oliver suggested. It may be that the API/ABI of these later versions will permit them to be used with sylpheed2 instead of the original oniguruma. Of course, you can always check this by looking at the code. b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Sylpheed doesn't compile on amd64
b. f. wrote: So I wonder why there is still a /usr/local/lib/libonig.a when oniguruma is deinstalled? ??? Probably because after deinstalling oniguruma, he tried to install sylpheed2 WITH_ONIGURUMA, so oniguruma was placed in sylpheed2's BUILD_DEPENDS, meaning that oniguruma was rebuilt and reinstalled as part of the sylpheed2 build. This is a non-default option, so it doesn't receive as much testing, and something may well be broken. Try rebuilding and reinstalling first oniguruma and then sylpheed2 with CFLAGS+=-fPIC, as the error message indicates. You may need to tinker with the linker flags as well. If that doesn't work, try removing oniguruma and then installing one of the later versions of oniguruma that uses shared libraries, as Oliver suggested. It may be that the API/ABI of these later versions will permit them to be used with sylpheed2 instead of the original oniguruma. Of course, you can always check this by looking at the code. I tested it once more - it fails with devel/oniguruma. I'll change the dependency to use oniguruma5 because this version works -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster is not always recursive
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Ok, I found the problem, but the bad news is that I don't know what the solution is going to be. I've cc'ed ale since what I'm seeing is weird behavior by the php5-mcrypt slave port. What portmaster does by default when looking for dependencies is to run 'make build-depends-list run-depends-list | sort -u' to get the list of things to check. I used to just do all-depends-list by default but users complained that it was creating problems by recursing so far down the tree. What I'm seeing in security/php5-mcrypt is that the union of {build|run}-depends-list is different if I run it in the slave port than if I run it in lang/php5 (after enabling the OPTION for apache): In the slave port: /usr/ports/devel/autoconf262 /usr/ports/devel/libltdl22 /usr/ports/lang/php5 /usr/ports/security/libmcrypt In lang/php5: /usr/ports/devel/autoconf262 /usr/ports/devel/pkg-config /usr/ports/textproc/libxml2 /usr/ports/www/apache22 That's why portmaster is not picking up the dependency on apache when updating php5-mcrypt. Miroslav, for your specific problem you can add the -t option to portmaster to force it to do all-depends-list, which will cause portmaster to see the apache dependency. Other than that I'm not sure how to proceed. I suppose that I could force all-depends-list if MASTERDIR is set in a Makefile, but I'm kind of hesitant to do that unless it becomes obvious that the problem is more widespread. hope this helps, Doug - -- This .signature sanitized for your protection -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (FreeBSD) iEYEAREDAAYFAkqasc8ACgkQyIakK9Wy8PuHsACbBFlBJWJL0hj8L1MtOc78fEq6 dN4AoKz4eCJRpquOh5BoYxr5Z3Dov+3c =1/H3 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster is not always recursive
Doug Barton wrote: Ok, I found the problem, but the bad news is that I don't know what the solution is going to be. I've cc'ed ale since what I'm seeing is weird behavior by the php5-mcrypt slave port. What portmaster does by default when looking for dependencies is to run 'make build-depends-list run-depends-list | sort -u' to get the list of things to check. I used to just do all-depends-list by default but users complained that it was creating problems by recursing so far down the tree. Does it mean that portmaster checks only first level dependencies unless -t is given? (Maybe it is good behavior, I am just asking it to be sure that I understand it well) real world example: If I do `portmaster amavisd-new-2.6.4_1,1` and there will be available update for archivers/p5-Compress-Raw-Bzip2 but not for dependencies between, it will not be updated, because it is too deep? The dependency tree is: security/amavisd-new mail/p5-Mail-SpamAssassin archivers/p5-Archive-Tar archivers/p5-IO-Compress-Bzip2 archivers/p5-Compress-Raw-Bzip2 What I'm seeing in security/php5-mcrypt is that the union of {build|run}-depends-list is different if I run it in the slave port than if I run it in lang/php5 (after enabling the OPTION for apache): In the slave port: /usr/ports/devel/autoconf262 /usr/ports/devel/libltdl22 /usr/ports/lang/php5 /usr/ports/security/libmcrypt In lang/php5: /usr/ports/devel/autoconf262 /usr/ports/devel/pkg-config /usr/ports/textproc/libxml2 /usr/ports/www/apache22 That's why portmaster is not picking up the dependency on apache when updating php5-mcrypt. I don't know the exact definition of slave port, but can it be that there are 2 types of slave ports? Where one type is for example proftpd-mysql, which conflicts with master port proftpd (only one of them can be installed) The second type is php5-mcrypt, which is only extension for master port and cannot be installed alone? Miroslav, for your specific problem you can add the -t option to portmaster to force it to do all-depends-list, which will cause portmaster to see the apache dependency. Other than that I'm not sure how to proceed. I suppose that I could force all-depends-list if MASTERDIR is set in a Makefile, but I'm kind of hesitant to do that unless it becomes obvious that the problem is more widespread. hope this helps, Yes, it really helps. Now I know my favorite ports mgmt tool better then before and as more I think about {build|run}-depends-list versus all-depends-list it seems that current behavior is better. And if someone wants all-depends-list, there is -t options. So all is fine. Maybe this difference can be explained in portmasters manual. (stating that normally {build|run}-depends-list is used and only first level of dependencies are checked/updated and if someone wants really recursive check, the -t option must be used) I can imagine some cases with long chain of dependencies (A - B - C - D - E) where user wants to update A, then B, C and D has no updates, but E has update. So if portmaster updates A and E, but not B, C, D it can cause some incompatibilities. Am I right? So in this view, updating only first level dependencies seems better. (but incompatible changes are usually solved by version bump and thus updates for B, C, D) So the last thought is some new option for portmaster to force reinstall of all intermediate dependencies between A and E, even if there are no updates for them. All above are just my thoughts... Thank you again for you explanation of the problem. It is really educational to me. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster is not always recursive
On Sun, 30 Aug 2009, Miroslav Lachman wrote: Doug Barton wrote: Ok, I found the problem, but the bad news is that I don't know what the solution is going to be. I've cc'ed ale since what I'm seeing is weird behavior by the php5-mcrypt slave port. What portmaster does by default when looking for dependencies is to run 'make build-depends-list run-depends-list | sort -u' to get the list of things to check. I used to just do all-depends-list by default but users complained that it was creating problems by recursing so far down the tree. Does it mean that portmaster checks only first level dependencies unless -t is given? (Maybe it is good behavior, I am just asking it to be sure that I understand it well) That's not exactly right, but it's about 90% right so close enough. :) The discrepancy relates to how individual ports report their dependencies, but for almost all purposes that is correct, yes. real world example: If I do `portmaster amavisd-new-2.6.4_1,1` and there will be available update for archivers/p5-Compress-Raw-Bzip2 but not for dependencies between, it will not be updated, because it is too deep? Assuming that the latter is not listed as a dependency by amavisd-new, then no, it will not be updated that way. I don't know the exact definition of slave port, but can it be that there are 2 types of slave ports? Where one type is for example proftpd-mysql, which conflicts with master port proftpd (only one of them can be installed) The second type is php5-mcrypt, which is only extension for master port and cannot be installed alone? I suspect that you are correct here, but I do not claim comprehensive knowledge of slave ports. :) I will add that there is at least one more type, e.g., editors/pico-alpine and mail/alpine where the former is a slave of the latter because it uses the same distfiles, same basic OPTIONS, etc; although they install totally different programs. Miroslav, for your specific problem you can add the -t option to portmaster to force it to do all-depends-list, which will cause portmaster to see the apache dependency. Other than that I'm not sure how to proceed. I suppose that I could force all-depends-list if MASTERDIR is set in a Makefile, but I'm kind of hesitant to do that unless it becomes obvious that the problem is more widespread. hope this helps, Yes, it really helps. Now I know my favorite ports mgmt tool better then before and as more I think about {build|run}-depends-list versus all-depends-list it seems that current behavior is better. And if someone wants all-depends-list, there is -t options. So all is fine. FWIW, there is always the -a option to update everything that needs it. Maybe this difference can be explained in portmasters manual. (stating that normally {build|run}-depends-list is used and only first level of dependencies are checked/updated and if someone wants really recursive check, the -t option must be used) I get two complaints about the manual. The first is that it does not cover enough of the details, the second is that it's too long. I don't know how to make both groups happy. :) I will think about adding something to the man page about this though. I should also point out that -t does not mean really recursive check. Portmaster is always recursive, the difference is not necessarily how deep it goes, it can also be how wide it goes as well. So the last thought is some new option for portmaster to force reinstall of all intermediate dependencies between A and E, even if there are no updates for them. The -f option already does this. Thank you again for you explanation of the problem. It is really educational to me. Glad to help. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Sylpheed doesn't compile on amd64
On Sun, Aug 30, 2009 at 4:09 PM, b. f. bf1...@googlemail.com wrote: ??? Probably because after deinstalling oniguruma, he tried to install sylpheed2 WITH_ONIGURUMA, so oniguruma was placed in sylpheed2's BUILD_DEPENDS, meaning that oniguruma was rebuilt and reinstalled as part of the sylpheed2 build. Correct. Removing oniguruma from sylpheed's options allows portupgrade to do its job on sylpheed without problems. No, I don't know why I enabled oniguruma in the first place. Probably thought it was a good idea at the time. -- Regards, Torfinn Ingolfsen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org