Re: Error building octave from port

2008-04-04 Thread Chris Waterson

On Apr 4, 2008, at 10:24 AM, Jean-François Gobin wrote:

Hi,

I'm trying to install octave. It chokes :

make -C ../../scripts DOCSTRINGS
make[4]: `DOCSTRINGS' is up to date.
making arith.texi from arith.txi
/bin/sh: line 1:  2592 Segmentation fault  ./munge-texi -d ../../ 
src/DOCSTRINGS -d ../../scripts/DOCSTRINGS  arith.txi  arith.texi-t

make[3]: *** [arith.texi] Error 139
make[2]: *** [interpreter] Error 2
make[1]: *** [doc] Error 2
make: *** [all] Error 2

Error: Status 1 encountered during processing.

Version is octave-2.9.15


See http://trac.macosforge.org/projects/macports/ticket/13686.   
There's a portfile in that ticket that can be used to build  
octave-3.0.0.


chris___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users


fftw-3, no .dylib?

2008-04-02 Thread Chris Waterson

Was --enabled-shared left off on purpose in the Portfile for fftw-3?

thanks!
chris

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users


adding self to cc list on tickets?

2008-03-12 Thread Chris Waterson
(Apologies in advance for the newbie question...)

Is there a way to add oneself to the cc list of a MacPorts Trac ticket  
that you didn't create?

thanks!
chris
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users


Re: g++-mp-4.2 executables bad on leopard?

2008-03-07 Thread Chris Waterson
On Mar 7, 2008, at 9:41 PM, Chris Waterson wrote:

 I was poking around at the octave build on Leopard (bug 13686), and
 I'm suspicious that g++-mp-4.2 is generating bad executables.

A couple additional data points:

   * gdb doesn't really seem to grok executables built with g++-mp-4.2

   * This problem doesn't happen with Apple's pre-release g++-4.2

chris
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users


hdf5 upgrade fails

2007-11-04 Thread Chris Waterson

Apologies if this has already been reported, but...

It turns out that the HDF5 build will fail when *upgrading* from  
1.6.5_0 to 1.6.6_0 with the following error:


gcc .libs/getnameS.o -O2 -std=c99 -Wno-long-long -O -fomit-frame- 
pointer -finline-functions -o .libs/getname getname.o  -L./.libs - 
lh5test -L/opt/local/lib -L/opt/local/lib/lib -L../src/.libs -lhdf5 - 
lz -lm
/usr/bin/ld: warning -L: directory name (/opt/local/lib/lib) does not  
exist

/usr/bin/ld: Undefined symbols:
_H5G_user_path_test
collect2: ld returned 1 exit status
make[2]: *** [getname] Error 1
make[1]: *** [tests] Error 1
make: *** [all] Error 2

This is because it finds the old libhdf5.a in /opt/local/lib before  
finding it in ../src/.libs (the local build directory).


I was able to work around this problem by:

  port uninstall -f hdf5
  port install hdf5

It would be nice to somehow patch or fix the software so that this  
doesn't bite other unwitting upgraders...


thanks!
chris


___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users


crufty old versions [was Re: (no subject)]

2007-07-10 Thread Chris Waterson

On Jul 10, 2007, at 8:59 PM, Ryan Schmidt wrote:



On Jul 10, 2007, at 18:49, Chris Waterson wrote:


Hi there!  I've been using macports for some time now, and one thing
that is frustrating is the fact that port upgrade leaves crufty old
variants behind.


You mean: crufty old versions behind. variants has a different  
meaning for MacPorts.


Thank you for the quick response...you're right: I meant versions.


I've tried:

  port -uR upgrade outdated

in the hopes that -u would uninstall non-active ports when
upgrading and uninstalling (as claimed by the man page) and that
combining it with -R would also upgrade dependents (by which I  
was

hoping upgrade meant rebuild with the newer variant).


Here I don't know what you mean by variant. If you're talking  
about variants in the way that MacPorts defines that term, then  
upgrade will only retain the set of variants with which you  
originally installed the port. If you now want to have a different  
set of variants on a port, then your only option is to completely  
uninstall (or at least deactivate) the existing port, and then  
install it with the variants you now want.


Again, my confusion.  I meant version where I said variant.

I wasn't familiar with -R. You're right, I see it's in the manpage.  
But MacPorts follows dependencies by default, so I don't think you  
need -R.



This doesn't seem to be the case, but leads to lots of extra warnings
during my upgrade, for example, the following (five times, or so):

  Error: Uninstall sqlite3 3.3.17_0+darwin_8 failed: Please  
uninstall the ports that depend on sqlite3 first.
  ---  Unable to uninstall sqlite3 3.3.17_0+darwin_8, the  
following ports depend on it:

  ---apr-util

At which point, for each piece of cruft, I wander through all the
dependents by hand, uninstall each, then uninstall the old variant,
then re-install each dependent.

Surely I am doing something wrong.  Can someone vend me a clue?


I recommend you do the following (substituting any other port name  
for sqlite3 as desired):


sudo port -u upgrade sqlite3

If you encounter an error that says it's required for other ports,  
then force the upgrade:


sudo port -ufn upgrade sqlite3

If other ports depend on sqlite3, then you need to force (-f) the  
uninstall. However, then you'll also want the nonrecursive flag (- 
n), else MacPorts will rebuild all of sqlite3's dependencies too,  
possibly even multiple times, which is just a waste of your time.  
The latter is a bug:


http://trac.macosforge.org/projects/macports/ticket/10827

Since you normally do want MacPorts to follow dependencies if  
necessary, you should always first try just upgrading with -u, and  
only if that fails, switch to -unf.



The fact that apr-util is listed five times in your output instead  
of once is also a bug:


http://trac.macosforge.org/projects/macports/ticket/8763


Okay, thanks for the pointers.

I did take a stab at port -ufn upgrade, but that seemed to *still*  
not get rid of the dependency.  As the below trace shows:


1. I can't uninstall gd2 @2.0.34_0 because gnuplot depends on it.

2. Rebuilding either gd2 or gnuplot does not clear the dependency.

3. But the dependency is (seems?) false, since I can port uninstall - 
f gd2 @2.0.34_0 and gnuplot will still run.  I suppose it's possible  
that gd2 is dlopen'd and gnuplot will fail splendidly later.


Anyway, it seems like there might just be some issues with dependency  
tracking.


Thanks for your help!

chris



~$ sudo port uninstall gd2
---  The following versions of gd2 are currently installed:
---gd2 @2.0.34_0
---gd2 @2.0.35_0 (active)
Error: port uninstall failed: Registry error: Please specify the full  
version as recorded in the port registry.

~$ sudo port uninstall gd2 @2.0.34_0
---  Unable to uninstall gd2 2.0.34_0, the following ports depend on  
it:

---gnuplot
Error: port uninstall failed: Please uninstall the ports that depend  
on gd2 first.

~$ sudo port -ufn upgrade gd2
---  Configuring gd2
---  Building gd2 with target all
---  Staging gd2 into destroot
---  Packaging tgz archive for gd2 2.0.35_0
---  Unable to uninstall gd2 2.0.35_0, the following ports depend on  
it:

---gnuplot
Warning: Uninstall forced.  Proceeding despite dependencies.
---  Deactivating gd2 2.0.35_0
---  Uninstalling gd2 2.0.35_0
---  Installing gd2 2.0.35_0
---  Activating gd2 2.0.35_0
---  Cleaning gd2
~$ sudo port uninstall gd2
---  The following versions of gd2 are currently installed:
---gd2 @2.0.34_0
---gd2 @2.0.35_0 (active)
Error: port uninstall failed: Registry error: Please specify the full  
version as recorded in the port registry.

~$ sudo port uninstall gd2 @2.0.34_0
---  Unable to uninstall gd2 2.0.34_0, the following ports depend on  
it:

---gnuplot
Error: port uninstall failed: Please uninstall the ports that depend  
on gd2 first.

~$ sudo port uninstall gnuplot
---  Unable to uninstall gnuplot 4.2.0_0, the following ports depend