Charlie,
The configure errors for the freebsd build are puzzling. It looks like the 'mv' commands executed by 'config.status' are failing. 'config.status' is created by 'configure', and it actually makes the Makefiles from Makefile.in. 'config.status' creates files in a temporary dir (like /tmp) and then moves then when finished to the build dir. It looks like some files get moved ok, but not others. Since 'config.status' is created each time, I'd need to see the freebsd's config.status. I modified 'configure.eg' to upload freebsd's config.status to dust. When you get a chance, try that build again. (perhaps look at my changes to configure.eg first to be sure I modified it correctly)
Also, the MacOS libnco build looks ok to me, but it doesn't try libnco_c++ because valarray is missing; do you have any idea if that should be the case?
And finally, does your linux --enable-dods build still fail? If so, can you upload the make.log since it seems to work here. However, we don't have a libnco_c++ test for it, yet.
rorik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, it looks like there is some sort of permissions problem with FREEBSD. The permissions of the
nco directories appear to 755 when you check it
out from CVS. Is this the appropriate setting?
I've rebuilt on FREEBSD so you can look at the logs.
The compile farm MACOSX system has an old g++,
2.95.2, which is missing valarray so it makes sense
not to try the nco_c++ build.
Yes, my DODS builds still fails in the link stage
I believe the problem is that two libraries need to
be specified twice to resolve dependencies, as in bld/Makefile and configure.in
Charlie,
Apparently 'libtool' strips out duplicate libraries. However, there is an undocumented options --preserve-dup-deps that we can use. I uploaded the change. Try your linux --enable-dods again when you get a chance.
rorik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using your --preserve-dup-deps change, the
number of unreselved functions dropped dramatically
when I tried to build, but there are still some remaining.
As far as the necessity of duplicating the libraries
in the dependency list, this is explicitly recommended in the DODS user's guide
I do not understand why it worked for you at all
before, because the bld/Makefile, which works
fine for DODS, has always needed and used
the duplicated dependencies.
One thing that is clear is that preserving duplicated
dependencies may cause problems on other
platforms whose linkers are not as forgiving as
linux. Most of the libraries are now linked like three
times! For this reason, and because you yourself
never needed preserve-dup-deps, I am glad you
only enable preserve-dup-deps for DODS builds.
In any case, I am hopeful that non-redhat platforms
will be able to build DODS even if I can't. It's a
nice feature of NCO but not one that I personally
use so I'm not going to worry about it anymore.
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Charlie,
The configure errors for the freebsd build are puzzling. It looks like the 'mv' commands executed by 'config.status' are failing. 'config.status' is created by 'configure', and it actually makes the Makefiles from Makefile.in. 'config.status' creates files in a temporary dir (like /tmp) and then moves then when finished to the build dir. It looks like some files get moved ok, but not others. Since 'config.status' is created each time, I'd need to see the freebsd's config.status. I modified 'configure.eg' to upload freebsd's config.status to dust. When you get a chance, try that build again. (perhaps look at my changes to configure.eg first to be sure I modified it correctly)
Also, the MacOS libnco build looks ok to me, but it doesn't try libnco_c++ because valarray is missing; do you have any idea if that should be the case?
And finally, does your linux --enable-dods build still fail? If so, can you upload the make.log since it seems to work here. However, we don't have a libnco_c++ test for it, yet.
rorik
Hi Rorik,
Thanks for looking into these build problems
Yes, it looks like there is some sort of permissions problem with FREEBSD. The permissions of the
nco directories appear to 755 when you check it
out from CVS. Is this the appropriate setting?
I've rebuilt on FREEBSD so you can look at the logs.
The compile farm MACOSX system has an old g++,
2.95.2, which is missing valarray so it makes sense
not to try the nco_c++ build.
Yes, my DODS builds still fails in the link stage
I believe the problem is that two libraries need to
be specified twice to resolve dependencies, as in bld/Makefile and configure.in
-lnc-dods -ldap++ -lnc-dods -ldap++ -lwww -lz -lrx
but the configure.log tell me they are only being
specified once:
-lnc-dods -ldap++ -lrx -lwww -lz
Can you verify/fix this?
Thanks,
Charlie
Charlie,
Apparently 'libtool' strips out duplicate libraries. However, there is an undocumented options --preserve-dup-deps that we can use. I uploaded the change. Try your linux --enable-dods again when you get a chance.
rorik
Using your --preserve-dup-deps change, the
number of unreselved functions dropped dramatically
when I tried to build, but there are still some remaining.
As far as the necessity of duplicating the libraries
in the dependency list, this is explicitly recommended in the DODS user's guide
http://www.unidata.ucar.edu/packages/dods/user/guide-html/guide_28.html
I do not understand why it worked for you at all
before, because the bld/Makefile, which works
fine for DODS, has always needed and used
the duplicated dependencies.
One thing that is clear is that preserving duplicated
dependencies may cause problems on other
platforms whose linkers are not as forgiving as
linux. Most of the libraries are now linked like three
times! For this reason, and because you yourself
never needed preserve-dup-deps, I am glad you
only enable preserve-dup-deps for DODS builds.
In any case, I am hopeful that non-redhat platforms
will be able to build DODS even if I can't. It's a
nice feature of NCO but not one that I personally
use so I'm not going to worry about it anymore.
Charlie