ncarg @6.1.2_1 missing ncl executable

[c.brierley@…]

Hello,

I'm having problems with the new NCL version. It installs without error and removes all the logs, but there is no "ncl" executable created. It does create other contingent executables such as /opt/local/bin/ncl_filedump though.

This sounds a similar problem to that raised by Ticket #28043. I'm using macports 2.1.3, OSX 10.8.3 and XQuartz 2.7.4. I've tried variants with both gcc44 and gcc47 to no avail.

This has come about due to an selfupdate, but it's been ages since my last one, so there could easily be some dependencies issues here unfortunately. I have previously had ncarg@6.0.0_5+gcc44 working. I'd be happy to give to any further information.

Cheers, Chris

[tenomoto (Takeshi Enomoto)]

First, I'd like to see the list of binaries you have now. Could you issue a command

port contents ncarg | grep /bin > ncarg_bin.txt

and upload ncarg/bin.txt

Secondly, could you build again and upload the log file? It should be /opt/local/var/macports/logs/*_ncarg/ncarg/main.log.

[c.brierley@…]

tailed version of main.log

[c.brierley@…]

Hi,

I've uploaded the files as requested. The directory with the main.log file is deleted at the end of the build - so I've taken a "tail -f " of it during the build. It hopefully is complete and not missing any lines, but I can't discount that.

Also I was worried about my selfupdating interfering with the ncarg build. As it was time for a clear out anyway, I've done a full uninstall/clean of all my ports. The only subsequent command I've run is:

sudo port install ncarg

The output files I've uploaded are from this installation.

Thanks

[ryandesign (Ryan Carsten Schmidt)]

On my system, ncarg installs 59 binaries; Chris, your list only has 27.

Seems like the ncarg build system does not detect when it runs into problems. Takeshi, the the first I'd do is have the port check (in a post-build block) that ncl (and perhaps some other key programs) got built, and exit with an error if not. See the cdrtools port for an example of how this can be done, though it can probably be simplified for ncarg, assuming its build location is always the same (cdrtools' varies by machine).

Chris, your log shows lots of errors like:

/opt/local/include/sys/fcntl.h:268: error: expected identifier or ‘(’ before ‘/’ token

/opt/local/include/sys/fcntl.h is provided by the xnu-headers port. Try deactivating that port (sudo port -f deactivate xnu-headers), then cleaning ncarg (sudo port clean ncarg) and trying the build again. Re-activate xnu-headers again afterward (sudo port activate xnu-headers) since it's probably a dependency of one of your other ports. I have installed xnu-headers now and am rebuilding ncarg now to see if I can reproduce the problem.

[ryandesign (Ryan Carsten Schmidt)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

I have installed xnu-headers now and am rebuilding ncarg now to see if I can reproduce the problem.

Yes, I can reproduce the problem.

One simple way to handle this would be to add these lines to the port:

PortGroup conflicts_build 1.0

conflicts_build-append xnu-headers

But it would be nice to know why they conflict like this, and to fix it if possible. I'll Cc the maintainer of xnu-headers for input.

[c.brierley@…]

I couldn't manage to deactivate the xnu-headers port properly and it still kept interacting with my ncarg build. However, I discovered that it's a dependency of gcc47.

I therefore built ncarg in the gcc46 variant (in a virgin ports enviroemtn) and it seems to be working perfectly, so I can get on with my model analyses. I know that's not the proper solution, but it gets me back up and running, so I'm really happy.

Thanks for all your help (and over the weekend too)!

[tenomoto (Takeshi Enomoto)]

I have been trying to find why ncarg fails with xnu-headers. The problematic headers, files.h and fcntl.h in /usr/include/sys and those of xnu-headers are identical. I don't see why. fcntl.h is included in file.h. I defined FreeBSD to use sys/filio.h instead of sys/file.h, but this didn't help.

I found that using macports-gcc-4.x, xnu-headers may be active. ncarg has not conformed UsingTheRightCompiler since one of ncl's function (setfileoption) caused segmentation fault. The current version doesn't seem to have this problem (I tested with gcc46 and gcc47). So I set configure.compiler for gcc4x and added conflicts_build for g95.

The problem occurs with llvm-gcc-4.2 and clang. A part of the problem might be /usr/include has fcntl.h but not in /opt/local/include. I continue to work on the problem.

Committed in r105081.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #39913.

[tenomoto (Takeshi Enomoto)]

In r108760, I added a number of patches that enable build with clang when +g95 is set. clang requires a return value in non-void functions. In some C source files, some functions are defined without type and are meant to be void. clang, however, assumes that they are int. nyacc uses this old style without explicit function type. If nyacc is not built, ncl cannot be built. These patches should not affect +gcc4x.

With +gcc4x and +accelerate, a mismatch occurred due to additional -ff2c flag that implies -fsecond-underscore. As far as I experimented, dotwrp does not require -ff2c or other underscore related flags with gfortran.

I was able to build ncarg with xnu-headers installed.

[pgf]

I experienced the same problem without xnu-headers installed.
Looking at the debug output (port -d install ncarg +gcc48) it seems a link time problem due to the use of the apple gcc for linking instead of the selected macports gcc. The linker fails because it can't find -lgfortran .

I solved adding the following line to the Portfile:

configure.compiler              macports-gcc-4.8

Hope this can help.

[pgf]

Cc Me!

[tenomoto (Takeshi Enomoto)]

I reverted the use of configure.compiler in r111452. See #40549. I'm not sure if it is related to the problem with xnu-headers.

[William.Capehart@…]

NCARG Build Log (Bill Capehart 03 Nov 2013, Macports 2.2.1)

[William.Capehart@…]

With Mavericks' install of MacPorts (2.2.1) I have the same problem. I fail to get the ncl program I am attaching a log file of the crash.

Note that I am also having a problem with installing libgcc and gcc48 which I have reported as ticket:40998

The failures in the build of ncarg appear to begin in ezmapdemo:

:info:build /opt/local/bin/gfortran-mp-4.8 -fPIC -fno-range-check -m64 -Wall  -Os    -o ezmapdemo EzmapDemo.o -L../../../.././ncarg2d/src/libncarg -lncarg -L../../../.././ncarg2d/src/libncarg_gks -lncarg_gks -L../../../.././common/src/libncarg_c -lncarg_c -lcairo -lfontconfig -lpixman-1 -lfreetype -lexpat -lpng -lz -lpthread -lbz2 -lXrender -lpng -lz -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_ncarg/ncarg/work/destroot/opt/local/lib -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_ncarg/ncarg/work/ncl_ncarg-6.1.2 -L/opt/local/lib -L/opt/local/lib/hdfeos5/lib -L/opt/local/lib  -lXpm -lX11 -lXext  
:info:build ld: warning: directory not found for option '-L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_ncarg/ncarg/work/destroot/opt/local/lib'
:info:build Undefined symbols for architecture x86_64:
:info:build   "_ardrln_", referenced from:
:info:build       _mdpiqm_ in libncarg.a(mdpiqm.o)
:info:build       _mdpitm_ in libncarg.a(mdpitm.o)
:info:build   "_aredam_", referenced from:
:info:build       _mdlnam_ in libncarg.a(mdlnam.o)
:info:build       _mdpbla_ in libncarg.a(mdpbla.o)
:info:build       _mdpiqa_ in libncarg.a(mdpiqa.o)
:info:build       _mdpita_ in libncarg.a(mdpita.o)
:info:build       _mdrgam_ in libncarg.a(mdrgam.o)
:info:build   "_argeti_", referenced from:
:info:build       _mdrgsx_ in libncarg.a(mdrgsx.o)
:info:build   "_argtai_", referenced from:
:info:build       _igetai_ in EzmapDemo.o
:info:build       _MAIN__ in EzmapDemo.o
:info:build   "_arinam_", referenced from:
:info:build       _MAIN__ in EzmapDemo.o
:info:build       _mdrgsx_ in libncarg.a(mdrgsx.o)
:info:build   "_arscam_", referenced from:
:info:build       _MAIN__ in EzmapDemo.o
:info:build       _mdrgsx_ in libncarg.a(mdrgsx.o)
:info:build   "_arseti_", referenced from:
:info:build       _mdrgsx_ in libncarg.a(mdrgsx.o)
:info:build   "_cpcldr_", referenced from:
:info:build       _coninv_ in EzmapDemo.o
:info:build   "_cprect_", referenced from:
:info:build       _coninv_ in EzmapDemo.o
:info:build   "_cpseti_", referenced from:
:info:build       _coninv_ in EzmapDemo.o
:info:build   "_cpsetr_", referenced from:
:info:build       _coninv_ in EzmapDemo.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build collect2: error: ld returned 1 exit status
:info:build make[5]: *** [ezmapdemo] Error 1

[William.Capehart@…]

Cc Me!

[tenomoto (Takeshi Enomoto)]

Fortran precompiler iftran does not seem to work properly. I'll see what I can do.

*** IFTRAN SUMMARY -  6099 CARDS,   0 ERRORS ***
../../../.././ncarg2d/src/libncarg/Iftran/Fsplit: Opening file "arblda.f".
../../../.././ncarg2d/src/libncarg/Iftran/Fsplit: Opening file "arblda.f".
make: *** [IftranRun] Abort trap: 6

[tenomoto (Takeshi Enomoto)]

strcpy() in ncarg2d/src/libncarg/IftranFsplit.c is found to cause SIGABORT. Not yet to find a way to fix it.

[tenomoto (Takeshi Enomoto)]

Fixed for Mavericks in r113131 using the strcpy fix in #41226

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #41902.

Replying to ryandesign@…:

Takeshi, the first I'd do is have the port check (in a post-build block) that ncl (and perhaps some other key programs) got built, and exit with an error if not. See the cdrtools port for an example of how this can be done, though it can probably be simplified for ncarg, assuming its build location is always the same (cdrtools' varies by machine).

This still needs to be done. The port currently detects that ncl didn't get built, but in that case it merely prints a message and continues instead of exiting. The attached patch fixes this, and a few other portfile issues, including removing unnecessary lines and using system's -W flag.

[ryandesign (Ryan Carsten Schmidt)]

proposed patch

[tenomoto (Takeshi Enomoto)]

In r117515.