Unable to build graphics/gd
I am unable to build the 'graphics/gd' port on FreeBSD-7.2 although I have updated the posts tree, etc. The build simply stops during the 'make' phase. A complete copy of the build log is available at this URL: http://pastebin.ca/1499985 This is an updated version of the 'gd' port. The previous version build without any problems. -- Jerry ges...@yahoo.com Who goeth a-borrowing goeth a-sorrowing. Thomas Tusser ___ 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: Unable to build graphics/gd
On, Sun Jul 19, 2009, Jerry wrote: I am unable to build the 'graphics/gd' port on FreeBSD-7.2 although I have updated the posts tree, etc. The build simply stops during the 'make' phase. A complete copy of the build log is available at this URL: http://pastebin.ca/1499985 Looks like it tries to link against the older version that's still installed. Try to deinstall gd first, then build and install it again. Regards Marcus pgpiJRGxQvGkH.pgp Description: PGP signature
Re: Unable to build graphics/gd
Le Sun, 19 Jul 2009 06:39:24 -0400, Jerry ges...@yahoo.com a écrit : I am unable to build the 'graphics/gd' port on FreeBSD-7.2 although I have updated the posts tree, etc. The build simply stops during the 'make' phase. A complete copy of the build log is available at this URL: http://pastebin.ca/1499985 There is a problem with libjpeg: /usr/bin/ld: warning: libjpeg.so.9, needed by /usr/local/lib/libgd.so, not found (try using -rpath or -rpath-link) Try to reinstall the port graphics/jpeg Regards. ___ 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: Unable to build graphics/gd
On Sun, 19 Jul 2009 13:00:30 +0200 Marcus von Appen m...@freebsd.org wrote: [snip] Looks like it tries to link against the older version that's still installed. Try to deinstall gd first, then build and install it again. Thanks, that fixed it. Strange, but I have not had that problem before. -- Jerry ges...@yahoo.com A general leading the State Department resembles a dragon commanding ducks. New York Times, Jan. 20, 1981 ___ 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: Unable to build graphics/gd
On, Sun Jul 19, 2009, Jerry wrote: On Sun, 19 Jul 2009 13:00:30 +0200 Marcus von Appen m...@freebsd.org wrote: [snip] Looks like it tries to link against the older version that's still installed. Try to deinstall gd first, then build and install it again. Thanks, that fixed it. Strange, but I have not had that problem before. Just for informational purposes: It is a problem with how the FreeBSD upgrade tools work and how a port (read: application, library, whatever) manages its own build. Usually a port, in case it links to one of its own components, should do that by using the just built component in its build directory. Some of them however do not do that but use the complete system environment, thus it can happen that they link to e.g. an older version of themselves or so, causing anything to fail as you just noticed. Regards Marcus pgp0JLNPOmsgo.pgp Description: PGP signature
Re: Unable to build graphics/gd
On Sun, 19 Jul 2009 12:58:56 +0200 dirk.me...@dinoex.sub.org (Dirk Meyer) wrote: [snip] libjpeg.so.9 is obsolete now. pelase use libjpeg.so.10 from jpeg-7. I all ready have the port installed. checking out the '/usr/local/lib' directory, reveals this: lrwxr-xr-x 1 root wheel13B Jul 19 09:01 libjpeg.so@ - libjpeg.so.10 -rwxr-xr-x 1 root wheel 222K Jul 19 09:01 libjpeg.so.10* I would assume that gd is being linked against the correct version. In any case, as I previously posted, deinstalling and reinstalling the 'gd' port fixed the problem; although I am not sure why the problem existed to begin with. -- Jerry ges...@yahoo.com Note to myself: use real bullets next time. ___ 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: Unable to build graphics/gd
On Sun, 19 Jul 2009 14:23:27 +0200 Marcus von Appen m...@freebsd.org wrote: On, Sun Jul 19, 2009, Jerry wrote: On Sun, 19 Jul 2009 13:00:30 +0200 Marcus von Appen m...@freebsd.org wrote: [snip] Looks like it tries to link against the older version that's still installed. Try to deinstall gd first, then build and install it again. Thanks, that fixed it. Strange, but I have not had that problem before. Just for informational purposes: It is a problem with how the FreeBSD upgrade tools work and how a port (read: application, library, whatever) manages its own build. Usually a port, in case it links to one of its own components, should do that by using the just built component in its build directory. Some of them however do not do that but use the complete system environment, thus it can happen that they link to e.g. an older version of themselves or so, causing anything to fail as you just noticed. Regards Marcus Thanks for the info. I appreciate it. I don't suppose that there is a recommended procedure to prevent just such an occurrence again in the future? Not that it is really all that important. I believe that this is the first time this has happened to me. -- Jerry ges...@yahoo.com If a can of Alpo costs 38 cents, would it cost $2.50 in Dog Dollars? ___ 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: FreeBSD Port: smalltalk-3.0.5
Greetings, Herby Vojčík wrote: I hope I am not very annoying, but I'd like to ask when will the port of 3.1 be ready. It features star packages with new clauses, which 3.0.5 cannot read, and better compstibility with other Smalltalk is also nice a feature. I was pretty disappointed that I cannot install Swazoo 2.2 since it\s packaged in 3.1 format. Let me add a little bit of background here: versions 3.0.5 and 3.1 were both released on the very same day: 3.0.5 is not older than 3.1. The former was a stable bugfix release and 3.1 came with serveral new features (and unfortunately no perfect backwards compatibility for running older programs). There were some minor issues (bugs) in 3.1 as well, although I don't remember the exact impact. At the time, there were no programs that used the new features and switching to it might cause problems for others. Right now, many programs will work with either version, and some even require the new 3.1 features (as you pointed out). I had expected that there would be a bugfix release for 3.1 by now with, so that I could upgrade to that version. But maybe the bugs aren't as important as I thought. I'll look in to these issues and will probably switch the port to 3.1(.x) soon. Regards, Johan pgpQvyMrCHe4B.pgp Description: PGP signature
Re: [HEADSUP]: Ports freeze schedule for 8.0-RELEASE
On Sat, July 18, 2009 1:36 am, Philip M. Gollucci wrote: Jeremy Messenger wrote: Hello all, It will be great if I can get more people to help test with libtool/libltdl 2.2 before the freeze. It already has been tested in pointyhat-exp last week, we have fixed almost all of error logs. Only three ports have been marked as BROKEN is x11-wm/ion-2, audio/ccaudio and lang/ccscript. If anyone want to fix those, feel free to or those will be remove if nobody fix it in a few months. I have sent an email to pav for request another run in pointyhat-exp. However, to test libtool/libltdl, you will need to checkout ports-stable module from MarcusCom CVS. sysutils/lsof DOES NOT COMPILE with libtool22. I don't believe sysutils/lsof is using libtool at all, in any way, shape, or form. I'd like to see what failure you're seeing. Thanks, Larry Rosenman (maintainer for sysutils/lsof). http://tb.p6m7g8.net live with libtool22, as far as I can tell the complete set below is fine -- HTH apache-2.2.11_7/ apr-gdbm-db42-mysql-1.3.6.1.3.8/ autoconf-2.62/ autoconf-wrapper-20071109/ automake-1.9.6_3/ automake-wrapper-20071109/ bash-static-4.0.24/ bison-2.4.1,1/ db42-4.2.52_5/ expat-2.0.1/ gdbm-1.8.3_3/ gmake-3.81_3/ help2man-1.36.4_3/ libiconv-1.13.1/ libtool-2.2.6a/ libxml2-2.7.3/ m4-1.4.13,1/ mysql-client-6.0.11/ mysql-scripts-6.0.11/ mysql-server-6.0.11/ p5-Authen-SASL-2.12/ p5-DBD-Pg-2.13.1/ p5-DBD-mysql60-4.012/ p5-DBI-1.60.7/ p5-Digest-HMAC-1.01/ p5-Digest-SHA1-2.12/ p5-Email-Date-Format-1.002/ p5-GSSAPI-0.26/ p5-HTML-Parser-3.61/ p5-HTML-Tagset-3.20/ p5-MIME-Lite-3.02.4/ p5-MIME-Types-1.27/ p5-Mail-Tools-2.04/ p5-Net-1.22_1,1/ p5-Proc-Queue-1.23/ p5-Storable-2.20/ p5-TimeDate-1.16,1/ p5-URI-1.38/ p5-libwww-5.829/ p5-version-0.76/ pcre-7.9/ pear-1.8.1/ pear-DB-1.7.13,1/ pear-MDB2-2.5.0.b2/ pear-MDB2_Driver_mysql-1.5.0.b2/ perl-5.10.0_4/ php5-5.2.10/ php5-mysql-5.2.10/ php5-pcre-5.2.10/ php5-session-5.2.10/ php5-xml-5.2.10/ pkg-config-0.23_1/ portscout-0.7.4_2/ postgresql-client-8.2.13/ postgresql-server-8.2.13/ python-2.6,2/ python26-2.6.2_1/ serf-0.3.0/ sqlite3-3.6.14.2/ subversion-1.6.3/ sudo-1.6.9.20/ tinderbox-devel-3.2_4/ vim-lite-7.2.209/ ___ 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 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ 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: [HEADSUP]: Ports freeze schedule for 8.0-RELEASE
On Sat, July 18, 2009 1:55 am, Philip M. Gollucci wrote: Joe Marcus Clarke wrote: What error did you get? I just compiled lsof-4.83A on 8.0-BETA2 with lt2.2, and it built just fine. http://people.freebsd.org/~pgollucci/lsof.txt my 8-current is a little old -- FreeBSD frieza.p6m7g8.net 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Thu Jun 4 00:22:57 EDT 2009 r...@frieza.p6m7g8.net:/usr/obj/usr/src/sys/FRIEZA amd64 That looks like you don't have all of /usr/src installed, and that it (potentially) doesn't match what's running. Please get /usr/src and the running kernel/world in sync, and sysutils/lsof should build just fine. Thanks, Larry Rosenman Maintainer sysutils/lsof ___ 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 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ 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
OSCAR port
Hello, I'm working in a project called OSCAR, for creating clusters, beowulf-class and I'd like to port it, how do I proceed? Do you think that the idea is viable? Many thanks and best regards -- Att; Enrique Fynn. ___ 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: OSCAR port
Enrique Fynn wrote: Hello, I'm working in a project called OSCAR, for creating clusters, beowulf-class and I'd like to port it, how do I proceed? Do you think that the idea is viable? Many thanks and best regards Hi, Of course it's possible ! A good starting point is the Porter Handbook[1] who gives you all the informations about the porting process. regards - Rodrigo [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.html ___ 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: Unable to build graphics/gd
On Sun, Jul 19, 2009 at 02:23:27PM +0200, Marcus von Appen wrote: On, Sun Jul 19, 2009, Jerry wrote: On Sun, 19 Jul 2009 13:00:30 +0200 Marcus von Appen m...@freebsd.org wrote: [snip] Looks like it tries to link against the older version that's still installed. Try to deinstall gd first, then build and install it again. Thanks, that fixed it. Strange, but I have not had that problem before. Just for informational purposes: It is a problem with how the FreeBSD upgrade tools work and how a port (read: application, library, whatever) manages its own build. Usually a port, in case it links to one of its own components, should do that by using the just built component in its build directory. Some of them however do not do that but use the complete system environment, thus it can happen that they link to e.g. an older version of themselves or so, causing anything to fail as you just noticed. In this case, the port was trying to link against the just built version of its shared library, it just also tries to link against some other libraries from other ports and puts -L/usr/local/lib earlier in the search path than the path to the newly built libgd.so so the linker picks up libgd.so from /usr/local/lib and uses that, hence the failure above. I saw the same problem. So just a little variant on what you said. Its trying to do the right thing but just getting the ordering wrong. -- Greg Lewis Email : gle...@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : gle...@freebsd.org ___ 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: OSCAR port
Oh! and where were you about three years ago, when a group of us were putting together our cluster, based around FreeBSD. We discovered how much of FreeBSD didn't work. For example we could never get ClusterIt! to work. An engineer delegated to work on this problem, literally one of the best debugger-oriented programmer's I have ever met, spent more than a week (about two?,) with this problem but was never able to isolate it. As you probably know debugging events across multiple machines isn't easy. We still have our cluster and we'd like to get it running. For several years we did run FreeBSD but were never able to get the level of performance that we would have obtained had we been running Linux or even something simpler, such as OS/2. Do you have a deliverable? On Sun, Jul 19, 2009 at 11:03 AM, Enrique Fynnenriquef...@gmail.com wrote: Hello, I'm working in a project called OSCAR, for creating clusters, beowulf-class and I'd like to port it, how do I proceed? Do you think that the idea is viable? Many thanks and best regards -- Att; Enrique Fynn. ___ freebsd-clus...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-cluster To unsubscribe, send any mail to freebsd-cluster-unsubscr...@freebsd.org ___ 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: OSCAR port
Jules Gilbert wrote: Oh! and where were you about three years ago, when a group of us were putting together our cluster, based around FreeBSD. We discovered how much of FreeBSD didn't work. For example we could never get ClusterIt! to work. An engineer delegated to work on this problem, literally one of the best debugger-oriented programmer's I have ever met, spent more than a week (about two?,) with this problem but was never able to isolate it. As you probably know debugging events across multiple machines isn't easy. We still have our cluster and we'd like to get it running. For several years we did run FreeBSD but were never able to get the level of performance that we would have obtained had we been running Linux or even something simpler, such as OS/2. Do you have a deliverable? You should look at Mozart/Oz (mozart.org) which is a largely theortical (but implemented) language that eliminates almost all the timing issues. I am slowly writing a distrusted OS based on some of the ideas. On Sun, Jul 19, 2009 at 11:03 AM, Enrique Fynnenriquef...@gmail.com wrote: Hello, I'm working in a project called OSCAR, for creating clusters, beowulf-class and I'd like to port it, how do I proceed? Do you think that the idea is viable? Many thanks and best regards -- Att; Enrique Fynn. ___ freebsd-clus...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-cluster To unsubscribe, send any mail to freebsd-cluster-unsubscr...@freebsd.org ___ 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 ___ 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: Unable to build graphics/gd
On Sunday 19 July 2009 11:08:31 am Greg Lewis wrote: On Sun, Jul 19, 2009 at 02:23:27PM +0200, Marcus von Appen wrote: On, Sun Jul 19, 2009, Jerry wrote: On Sun, 19 Jul 2009 13:00:30 +0200 Marcus von Appen m...@freebsd.org wrote: [snip] Looks like it tries to link against the older version that's still installed. Try to deinstall gd first, then build and install it again. Thanks, that fixed it. Strange, but I have not had that problem before. Just for informational purposes: It is a problem with how the FreeBSD upgrade tools work and how a port (read: application, library, whatever) manages its own build. Usually a port, in case it links to one of its own components, should do that by using the just built component in its build directory. Some of them however do not do that but use the complete system environment, thus it can happen that they link to e.g. an older version of themselves or so, causing anything to fail as you just noticed. In this case, the port was trying to link against the just built version of its shared library, it just also tries to link against some other libraries from other ports and puts -L/usr/local/lib earlier in the search path than the path to the newly built libgd.so so the linker picks up libgd.so from /usr/local/lib and uses that, hence the failure above. I saw the same problem. So just a little variant on what you said. Its trying to do the right thing but just getting the ordering wrong. I did the recursive pkg_delete as specified in UPDATING and now I have an unworkable KDE. Everything wants to reinstall jpeg-6, which fails because it is already installed. That left me with around 20 modules required by KDE that wouldn't build. When the current portupgrade fails, I will do the PKG_FORCE thing but I shouldn't have to do that. GD not building is just a small piece of the problem. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ 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: FreeBSD Port: smalltalk-3.0.5
Johan van Selst joh...@stack.nl wrote: ... versions 3.0.5 and 3.1 were both released on the very same day: 3.0.5 is not older than 3.1. The former was a stable bugfix release and 3.1 came with serveral new features (and unfortunately no perfect backwards compatibility for running older programs) ... Right now, many programs will work with either version, and some even require the new 3.1 features ... I'll look in to these issues and will probably switch the port to 3.1(.x) soon. Given the backwards compatibility issues, might it be worthwhile to create a new smalltalk31 or smalltalk-devel port, or rename the current port to something like smalltalk30x, so that the older version can remain available for use with older programs? ___ 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: Unable to build graphics/gd
Greg Lewis gle...@eyesbeyond.com wrote: Marcus von Appen m...@freebsd.org wrote: It is a problem with how the FreeBSD upgrade tools work and how a port (read: application, library, whatever) manages its own build. Usually a port, in case it links to one of its own components, should do that by using the just built component in its build directory. Some of them however do not do that but use the complete system environment, thus it can happen that they link to e.g. an older version of themselves or so, causing anything to fail as you just noticed. In this case, the port was trying to link against the just built version of its shared library, it just also tries to link against some other libraries from other ports and puts -L/usr/local/lib earlier in the search path than the path to the newly built libgd.so so the linker picks up libgd.so from /usr/local/lib and uses that, hence the failure above. I saw the same problem. So just a little variant on what you said. Its trying to do the right thing but just getting the ordering wrong. Might I suggest that one of you file a PR to get the port's library search path fixed, if not already done? To answer the earlier question of how to prevent this sort of problem when installing, I think one way would be to deinstall (making a backup package, to simplify recovery if the new version does not work) before building the new version. ___ 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
