octave-dev

[OctDev] Build problems with gcc 4.1

[Quentin S. <qsp...@ie...>]

I'm in the process of trying to get octave-forge to build with 2.9.4 for 
the upcoming Fedora Core 5, which will be using gcc 4.1. I finally got 
everything patched so it will build on Fedora Core 4 (gcc 4.0), but on 
the FC5 test release with gcc, it still fails. It appears that there are 
quite a lot of errors in the fixed point code, but I haven't had time to 
try debugging it. This is likely because gcc 4.1 is more strict in 
enforcing C++ standards. Anyway, I thought I'd send out a notice about 
this in case someone feels like figuring out what needs to be fixed in 
the fixed point code.

-Quentin

Re: [OctDev] Build problems with gcc 4.1

[David B. <Dav...@mo...>]

Quentin Spencer a =E9crit :

> I'm in the process of trying to get octave-forge to build with 2.9.4 fo=
r
> the upcoming Fedora Core 5, which will be using gcc 4.1. I finally got
> everything patched so it will build on Fedora Core 4 (gcc 4.0), but on
> the FC5 test release with gcc, it still fails. It appears that there ar=
e
> quite a lot of errors in the fixed point code, but I haven't had time t=
o
> try debugging it. This is likely because gcc 4.1 is more strict in
> enforcing C++ standards. Anyway, I thought I'd send out a notice about
> this in case someone feels like figuring out what needs to be fixed in
> the fixed point code.
>
> -Quentin
>
Quentin,

I don't curently have a machine with g++ 4.1 installed, so I can't fix=20
this. However, I'd like to see it fixed, so if you can supply me with=20
the compile logs giving the errors off-line I'll attempt a fix...

D.

Re: [OctDev] Build problems with gcc 4.1

[Thomas W. <tho...@gm...>]

Hi David,

Am Samstag, den 04.02.2006, 20:36 +0100 schrieb David Bateman:
> I don't curently have a machine with g++ 4.1 installed, so I can't fix 
> this. However, I'd like to see it fixed, so if you can supply me with 
> the compile logs giving the errors off-line I'll attempt a fix...

If it helps, a build log of a failed build with gcc-4.1 is available at 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357651


Regards
	Thomas

Re: [OctDev] Build problems with gcc 4.1

[David B. <Dav...@mo...>]

Thomas Weber wrote:

>Hi David,
>
>Am Samstag, den 04.02.2006, 20:36 +0100 schrieb David Bateman:
>  
>
>>I don't curently have a machine with g++ 4.1 installed, so I can't fix 
>>this. However, I'd like to see it fixed, so if you can supply me with 
>>the compile logs giving the errors off-line I'll attempt a fix...
>>    
>>
>
>If it helps, a build log of a failed build with gcc-4.1 is available at 
>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357651
>
>
>Regards
>	Thomas
>  
>
Thomas,

I believe Paul fixed this, which was one of the motivating factors for
the 2006-03-16 release...

Regards
David

-- 
David Bateman                                Dav...@mo...
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary

Re: [OctDev] Build problems with gcc 4.1

[Rafael L. <rla...@us...>]

* David Bateman <Dav...@mo...> [2006-03-22 10:43]:

> Thomas Weber wrote:
> >If it helps, a build log of a failed build with gcc-4.1 is available at 
> >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357651
> 
> I believe Paul fixed this, which was one of the motivating factors for
> the 2006-03-16 release...

Indeed, the bug report above regards version 2006.01.28.
 
-- 
Rafael

Re: [OctDev] Build problems with gcc 4.1

[Alexander B. <ab...@ma...>]

Hi Quentin,

I'm glad to see that my octcdf toolbox is included in the Fedora Core 5 
octave-forge package.
However, it seems that the package is not linked against the nc-dap 
library. Any call to the toolbox stops octave with a message like:

octave:1> example_netcdf
octave: symbol lookup error: 
/usr/libexec/octave/site/oct/api-v17/x86_64-unknown-linux-gnu/octave-forge/ov-netcdf.oct: 
undefined symbol: nc_create

Since the nc-dap library is included in FC5, I guess that this is not 
too difficult to fix. The configure script (main/octcdf/configure.add) 
should detect the the location of the nc-dap libraries using the 
ncdap-config script included in libnc-dap-devel.

Alternatively, octcdf can be linked against the NetCDF library, but this 
would reduce its functionality since only local files can be accessed 
with the NetCDF library. With nc-dap, local files and data sets on a 
OpenDAP server can be imported in octave.

Thanks and regards
Alex

Quentin Spencer wrote:
> I'm in the process of trying to get octave-forge to build with 2.9.4 
> for the upcoming Fedora Core 5, which will be using gcc 4.1. I finally 
> got everything patched so it will build on Fedora Core 4 (gcc 4.0), 
> but on the FC5 test release with gcc, it still fails. It appears that 
> there are quite a lot of errors in the fixed point code, but I haven't 
> had time to try debugging it. This is likely because gcc 4.1 is more 
> strict in enforcing C++ standards. Anyway, I thought I'd send out a 
> notice about this in case someone feels like figuring out what needs 
> to be fixed in the fixed point code.
>
> -Quentin
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>


-- 
_______________________________________________________________

  Alexander Barth

  Ocean Circulation Group
  University of South Florida
  College of Marine Science
  140 Seventh Avenue South 
  St. Petersburg, Florida  33701
  USA

  Phone: +1-727-553-3508     FAX:   +1-727-553-1189

_______________________________________________________________

Re: [OctDev] Build problems with gcc 4.1

[Quentin S. <qsp...@ie...>]

Alexander Barth wrote:

> Hi Quentin,
>
> I'm glad to see that my octcdf toolbox is included in the Fedora Core 
> 5 octave-forge package.
> However, it seems that the package is not linked against the nc-dap 
> library. Any call to the toolbox stops octave with a message like:
>
> octave:1> example_netcdf
> octave: symbol lookup error: 
> /usr/libexec/octave/site/oct/api-v17/x86_64-unknown-linux-gnu/octave-forge/ov-netcdf.oct: 
> undefined symbol: nc_create
>
> Since the nc-dap library is included in FC5, I guess that this is not 
> too difficult to fix. The configure script (main/octcdf/configure.add) 
> should detect the the location of the nc-dap libraries using the 
> ncdap-config script included in libnc-dap-devel.
>
> Alternatively, octcdf can be linked against the NetCDF library, but 
> this would reduce its functionality since only local files can be 
> accessed with the NetCDF library. With nc-dap, local files and data 
> sets on a OpenDAP server can be imported in octave.


I didn't know about nc-dap. It's currently linking to netcdf (at least 
it finds netcdf when I run configure), but apparently there's still 
something wrong. I've noticed you've made quite a lot of updates to CVS. 
Do I need current CDF, or will the last release (2006.03.17) work? Does 
nc-dap replace or supplement netcdf? I tried running configure with 
libnc-dap-devel instaled, and it looked like it was still looking for 
netcdf.

-Quentin

Re: [OctDev] Build problems with gcc 4.1

[Alexander B. <ab...@ma...>]

Hi Quentin,

I downloaded the 2006.03.17 release and I found a bug in the 
configure.add script. I attached the corrected version which simply 
replaces the version you have. For a built of octcdf with NetCDF, I did 
the following steps:

$ which ncdap-config
/usr/bin/which: no ncdap-config in ( ... )       # good
$ autogen.sh; CPPFLAGS=-I/usr/include/netcdf-3 
LDFLAGS=-L/usr/lib64/netcdf-3 ./configure
[...]
checking for nc-dap... no
checking for nc_open in -lnetcdf... yes
checking netcdf.h usability... yes
checking netcdf.h presence... yes
[...]
$ cd main/octcdf/
$ make
$ for i in *octlink; do ln -s ov-netcdf.oct  ${i%link}; done    # You 
have probably a better way of doing links instead of octlink files
$ octave -f
octave:1> nctest
writing test output to nctest.log
 >>>>> /home/abarth/Download/octave-forge-2006.03.17/main/octcdf/nctest.m
PASSES 17 out of 17 tests


But since OpenDAP supersedes the functionality of NetCDF, I think an 
OpenDAP built would be more useful.

$ ncdap-config --libs
-L/usr/lib64 -lnc-dap  -L/usr/lib64 -ldap  -L/usr/lib64 -lcurl 
-L/usr/kerberos/lib64 -lssl -lcrypto -ldl -lz -lgssapi_krb5 -lkrb5 
-lk5crypto -lkrb5support -lcom_err -lresolv -lidn -lssl -lcrypto -lz 
-lxml2 -lz -lm -lpthread           # good
$ autogen.sh; ./configure
[...]
checking for nc-dap... yes
[...]
$ cd main/octcdf/
$ make
$ for i in *octlink; do ln -s ov-netcdf.oct  ${i%link}; done
$ octave -f
octave:1> nctest
writing test output to nctest.log
 >>>>> /home/abarth/Download/octave-forge-2006.03.17/main/octcdf/nctest.m
PASSES 17 out of 17 tests

You probably don't need the information in all those details and you 
have your own way of doing the build. The current CVS version doesn't 
work with octave-2.9.4-8.fc5. I needed to undo some changes ("Commit 
changes from JWE for octave_value/octave_base_value changes in 2.9.5+") 
made by adb014 (David Bateman ?) in my local copy to make things work. 
But I haven't had time to dig in this problem.

Thanks,
Cheers
Alex


Quentin Spencer wrote:
> Alexander Barth wrote:
>
>> Hi Quentin,
>>
>> I'm glad to see that my octcdf toolbox is included in the Fedora Core 
>> 5 octave-forge package.
>> However, it seems that the package is not linked against the nc-dap 
>> library. Any call to the toolbox stops octave with a message like:
>>
>> octave:1> example_netcdf
>> octave: symbol lookup error: 
>> /usr/libexec/octave/site/oct/api-v17/x86_64-unknown-linux-gnu/octave-forge/ov-netcdf.oct: 
>> undefined symbol: nc_create
>>
>> Since the nc-dap library is included in FC5, I guess that this is not 
>> too difficult to fix. The configure script 
>> (main/octcdf/configure.add) should detect the the location of the 
>> nc-dap libraries using the ncdap-config script included in 
>> libnc-dap-devel.
>>
>> Alternatively, octcdf can be linked against the NetCDF library, but 
>> this would reduce its functionality since only local files can be 
>> accessed with the NetCDF library. With nc-dap, local files and data 
>> sets on a OpenDAP server can be imported in octave.
>
>
> I didn't know about nc-dap. It's currently linking to netcdf (at least 
> it finds netcdf when I run configure), but apparently there's still 
> something wrong. I've noticed you've made quite a lot of updates to 
> CVS. Do I need current CDF, or will the last release (2006.03.17) 
> work? Does nc-dap replace or supplement netcdf? I tried running 
> configure with libnc-dap-devel instaled, and it looked like it was 
> still looking for netcdf.
>
> -Quentin
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job 
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>


-- 
_______________________________________________________________

  Alexander Barth

  Ocean Circulation Group
  University of South Florida
  College of Marine Science
  140 Seventh Avenue South 
  St. Petersburg, Florida  33701
  USA

  Phone: +1-727-553-3508     FAX:   +1-727-553-1189

_______________________________________________________________

Re: [OctDev] Build problems with gcc 4.1

[Quentin S. <qsp...@ie...>]

Alexander Barth wrote:
> I downloaded the 2006.03.17 release and I found a bug in the 
> configure.add script. I attached the corrected version which simply 
> replaces the version you have.
Thanks. That seems to fix the configuration problem.


> The current CVS version doesn't work with octave-2.9.4-8.fc5. I needed 
> to undo some changes ("Commit changes from JWE for 
> octave_value/octave_base_value changes in 2.9.5+") made by adb014 
> (David Bateman ?) in my local copy to make things work. But I haven't 
> had time to dig in this problem.
It doesn't work with 2.9.5 either. The problem appears to be that "which 
ov-netcdf" does not give the path to ov-netcdf.oct as expected. As far 
as I can tell, this appears to be due to the presence of the "-" 
character, which seems to be confusing the octave parser. I don't know 
if this is intended behavior in octave or not, but you could work around 
it by renaming ov-netcdf.oct to ov_netcdf.oct (and making the 
appriopriate changes to all the other things that link to it).

-Quentin

Re: [OctDev] Build problems with gcc 4.1

[Alexander B. <ab...@ma...>]

Quentin Spencer wrote:
> Alexander Barth wrote:
>> I downloaded the 2006.03.17 release and I found a bug in the 
>> configure.add script. I attached the corrected version which simply 
>> replaces the version you have.
> Thanks. That seems to fix the configuration problem.
>
>
>> The current CVS version doesn't work with octave-2.9.4-8.fc5. I 
>> needed to undo some changes ("Commit changes from JWE for 
>> octave_value/octave_base_value changes in 2.9.5+") made by adb014 
>> (David Bateman ?) in my local copy to make things work. But I haven't 
>> had time to dig in this problem.
> It doesn't work with 2.9.5 either. The problem appears to be that 
> "which ov-netcdf" does not give the path to ov-netcdf.oct as expected. 
> As far as I can tell, this appears to be due to the presence of the 
> "-" character, which seems to be confusing the octave parser. I don't 
> know if this is intended behavior in octave or not, but you could work 
> around it by renaming ov-netcdf.oct to ov_netcdf.oct (and making the 
> appriopriate changes to all the other things that link to it).
Are you packing the CVS version of octave-forge or release 2006.03.17 ?

On my end, octcdf from release 2006.03.17 compiled from source actually 
do work with octave-2.9.4-8.fc5 and octave-2.9.5-2.fc5. In case you are 
using the CVS version, you would need the CVS version of today (2nd May) 
for octcdf.

Concerning the hyphen in ov-netcdf.oct, I can make the change if it is 
really necessary, but it  never posed a problem to me. Instead of "which 
ov-netcdf" you can type "which netcdf":
octave:1> which netcdf
netcdf is the dynamically-linked function from the file
/home/abarth/Octave/octcdf/netcdf.oct

Did you tried to run example_netcdf.m or nctest.m ?

In order to verify if ov-netcdf.oct contains undefined symbol, you can 
check the linked libraries with:
$ ldd ov-netcdf.oct
        libnc-dap.so.3 => /usr/lib64/libnc-dap.so.3 (0x00002aaaaabfc000)
[...]
The ov-netcdf.oct file in octave-forge seems not to be linked against 
nc-dap (or netcdf).

Thanks and regards,
Alex

>
> -Quentin
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job 
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>


-- 
_______________________________________________________________

  Alexander Barth

  Ocean Circulation Group
  University of South Florida
  College of Marine Science
  140 Seventh Avenue South 
  St. Petersburg, Florida  33701
  USA

  Phone: +1-727-553-3508     FAX:   +1-727-553-1189

_______________________________________________________________

Re: [OctDev] Build problems with gcc 4.1

[Quentin S. <qsp...@ie...>]

Alexander Barth wrote:
> Quentin Spencer wrote:
>> Alexander Barth wrote:
>>> I downloaded the 2006.03.17 release and I found a bug in the 
>>> configure.add script. I attached the corrected version which simply 
>>> replaces the version you have.
>> Thanks. That seems to fix the configuration problem.
>>
>>
>>> The current CVS version doesn't work with octave-2.9.4-8.fc5. I 
>>> needed to undo some changes ("Commit changes from JWE for 
>>> octave_value/octave_base_value changes in 2.9.5+") made by adb014 
>>> (David Bateman ?) in my local copy to make things work. But I 
>>> haven't had time to dig in this problem.
>> It doesn't work with 2.9.5 either. The problem appears to be that 
>> "which ov-netcdf" does not give the path to ov-netcdf.oct as 
>> expected. As far as I can tell, this appears to be due to the 
>> presence of the "-" character, which seems to be confusing the octave 
>> parser. I don't know if this is intended behavior in octave or not, 
>> but you could work around it by renaming ov-netcdf.oct to 
>> ov_netcdf.oct (and making the appriopriate changes to all the other 
>> things that link to it).
> Are you packing the CVS version of octave-forge or release 2006.03.17 ?
I'm using 2006.03.17, with a lot of patches for compatibility with 
octave 2.9.5.

> On my end, octcdf from release 2006.03.17 compiled from source 
> actually do work with octave-2.9.4-8.fc5 and octave-2.9.5-2.fc5. In 
> case you are using the CVS version, you would need the CVS version of 
> today (2nd May) for octcdf.
>
> Concerning the hyphen in ov-netcdf.oct, I can make the change if it is 
> really necessary, but it  never posed a problem to me. Instead of 
> "which ov-netcdf" you can type "which netcdf":
> octave:1> which netcdf
> netcdf is the dynamically-linked function from the file
> /home/abarth/Octave/octcdf/netcdf.oct
>
> Did you tried to run example_netcdf.m or nctest.m ?
>
> In order to verify if ov-netcdf.oct contains undefined symbol, you can 
> check the linked libraries with:
> $ ldd ov-netcdf.oct
>        libnc-dap.so.3 => /usr/lib64/libnc-dap.so.3 (0x00002aaaaabfc000)
> [...]
> The ov-netcdf.oct file in octave-forge seems not to be linked against 
> nc-dap (or netcdf).

With your configure.add patch, there's no problem linking to the 
libraries. The problem is that with octave 2.9.5 and later, octave-forge 
no longer creates symbolic links for cases where a DLD_FUNCTION a is 
found in b.oct. Instead, it uses the autoload function, using syntax 
something like: autoload("a","b.oct"). (This was done to for the benefit 
of cygwin, which I understand doesn't deal with symlinks well.) So, when 
you build octave-forge, instead of symlinking ncatt.oct to 
ov-netcdf.oct, it does this:
autoload ("ncatt", which ("ov-netcdf"));

It turns out the problem with this is not the '-' character in 
ov-netcdf, but the fact that octave apparently can't find ov-netcdf if 
it does not contain a DLD_FUNCTION ov-netcdf, although I'm sure it 
probably couldn't given C naming rules. I tried patching the Makefile to 
name the file ov_netcdf.oct, but that doesn't solve the problem. 
However, naming it netcdf.oct does, because it contains a function 
called netcdf.oct. The reason you are not seeing this problem is 
probably that you are not building all of octave-forge but only octcdf. 
The Makefile in the octcdf directory does something different in that 
case--it creates the symbolic links. That still works with octave-2.9.4 
and 2.9.5, but it doesn't solve the problem for someone packing all of 
octave-forge. You can go ahead and send a bug report if you think octave 
shouldn't do this, but regardless, I was able to get it to work properly 
with the following patch:


Index: main/octcdf/Makefile
===================================================================
RCS file: /cvsroot/octave/octave-forge/main/octcdf/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- main/octcdf/Makefile        19 Apr 2006 19:09:51 -0000      1.6
+++ main/octcdf/Makefile        28 Apr 2006 17:51:17 -0000
@@ -34,7 +34,7 @@
        RM = rm -f
 endif

-NCTARGET = ov-netcdf.oct
+NCTARGET = netcdf.oct

 NCSOURCES = ov-netcdf.cc ov-ncfile.cc ov-ncvar.cc ov-ncatt.cc ov-ncdim.cc
 OBJECTS = $(patsubst %.cc,%.o,$(NCSOURCES))

Re: [OctDev] Build problems with gcc 4.1

[Alexander B. <ab...@ma...>]

Hi Quentin,
You are right, I didn't test the autoload feature using octlinks. I will 
also change the NCTARGET in CVS accordingly.

Thanks again,
Alex

Quentin Spencer wrote:
> Alexander Barth wrote:
>> Quentin Spencer wrote:
>>> Alexander Barth wrote:
>>>> I downloaded the 2006.03.17 release and I found a bug in the 
>>>> configure.add script. I attached the corrected version which simply 
>>>> replaces the version you have.
>>> Thanks. That seems to fix the configuration problem.
>>>
>>>
>>>> The current CVS version doesn't work with octave-2.9.4-8.fc5. I 
>>>> needed to undo some changes ("Commit changes from JWE for 
>>>> octave_value/octave_base_value changes in 2.9.5+") made by adb014 
>>>> (David Bateman ?) in my local copy to make things work. But I 
>>>> haven't had time to dig in this problem.
>>> It doesn't work with 2.9.5 either. The problem appears to be that 
>>> "which ov-netcdf" does not give the path to ov-netcdf.oct as 
>>> expected. As far as I can tell, this appears to be due to the 
>>> presence of the "-" character, which seems to be confusing the 
>>> octave parser. I don't know if this is intended behavior in octave 
>>> or not, but you could work around it by renaming ov-netcdf.oct to 
>>> ov_netcdf.oct (and making the appriopriate changes to all the other 
>>> things that link to it).
>> Are you packing the CVS version of octave-forge or release 2006.03.17 ?
> I'm using 2006.03.17, with a lot of patches for compatibility with 
> octave 2.9.5.
>
>> On my end, octcdf from release 2006.03.17 compiled from source 
>> actually do work with octave-2.9.4-8.fc5 and octave-2.9.5-2.fc5. In 
>> case you are using the CVS version, you would need the CVS version of 
>> today (2nd May) for octcdf.
>>
>> Concerning the hyphen in ov-netcdf.oct, I can make the change if it 
>> is really necessary, but it  never posed a problem to me. Instead of 
>> "which ov-netcdf" you can type "which netcdf":
>> octave:1> which netcdf
>> netcdf is the dynamically-linked function from the file
>> /home/abarth/Octave/octcdf/netcdf.oct
>>
>> Did you tried to run example_netcdf.m or nctest.m ?
>>
>> In order to verify if ov-netcdf.oct contains undefined symbol, you 
>> can check the linked libraries with:
>> $ ldd ov-netcdf.oct
>>        libnc-dap.so.3 => /usr/lib64/libnc-dap.so.3 (0x00002aaaaabfc000)
>> [...]
>> The ov-netcdf.oct file in octave-forge seems not to be linked against 
>> nc-dap (or netcdf).
>
> With your configure.add patch, there's no problem linking to the 
> libraries. The problem is that with octave 2.9.5 and later, 
> octave-forge no longer creates symbolic links for cases where a 
> DLD_FUNCTION a is found in b.oct. Instead, it uses the autoload 
> function, using syntax something like: autoload("a","b.oct"). (This 
> was done to for the benefit of cygwin, which I understand doesn't deal 
> with symlinks well.) So, when you build octave-forge, instead of 
> symlinking ncatt.oct to ov-netcdf.oct, it does this:
> autoload ("ncatt", which ("ov-netcdf"));
>
> It turns out the problem with this is not the '-' character in 
> ov-netcdf, but the fact that octave apparently can't find ov-netcdf if 
> it does not contain a DLD_FUNCTION ov-netcdf, although I'm sure it 
> probably couldn't given C naming rules. I tried patching the Makefile 
> to name the file ov_netcdf.oct, but that doesn't solve the problem. 
> However, naming it netcdf.oct does, because it contains a function 
> called netcdf.oct. The reason you are not seeing this problem is 
> probably that you are not building all of octave-forge but only 
> octcdf. The Makefile in the octcdf directory does something different 
> in that case--it creates the symbolic links. That still works with 
> octave-2.9.4 and 2.9.5, but it doesn't solve the problem for someone 
> packing all of octave-forge. You can go ahead and send a bug report if 
> you think octave shouldn't do this, but regardless, I was able to get 
> it to work properly with the following patch:
>
>
> Index: main/octcdf/Makefile
> ===================================================================
> RCS file: /cvsroot/octave/octave-forge/main/octcdf/Makefile,v
> retrieving revision 1.6
> diff -u -r1.6 Makefile
> --- main/octcdf/Makefile        19 Apr 2006 19:09:51 -0000      1.6
> +++ main/octcdf/Makefile        28 Apr 2006 17:51:17 -0000
> @@ -34,7 +34,7 @@
>        RM = rm -f
> endif
>
> -NCTARGET = ov-netcdf.oct
> +NCTARGET = netcdf.oct
>
> NCSOURCES = ov-netcdf.cc ov-ncfile.cc ov-ncvar.cc ov-ncatt.cc ov-ncdim.cc
> OBJECTS = $(patsubst %.cc,%.o,$(NCSOURCES))
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job 
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>


-- 
_______________________________________________________________

  Alexander Barth

  Ocean Circulation Group
  University of South Florida
  College of Marine Science
  140 Seventh Avenue South 
  St. Petersburg, Florida  33701
  USA

  Phone: +1-727-553-3508     FAX:   +1-727-553-1189

_______________________________________________________________