Graphical Forecast Editor / Tickets / #19 Mac OSX Support

Mike Romberg - 2019-01-08

Quite a while back (years ago) I was able to compile and run the gfe on osx. It did mostly work and was not too difficult if I remember correclty. The code has probably become a bit more portable since then. So, it should (in theory) be doable now.

However, I no longer have access to any machine that runs osx. I know

osx is loosly based on one of the BSD variants. I could probably make it work on those. But
there are probably osx specific quirks that would need to be addressed in the makefiles to get
a clean osx build.

In the above specific case you posed, it looks like the way you

build shared object files (.so files) on osx differes somewhat from how it works on linux. It
may be that a different variant of -fpic (such as -fPIC) is needed on osx. And it could be
that some more libraries need to be added to the linker when these .so files are built due
to the dynamic linking working differently on osx versus linux.

If it were me, I would simply try commenting out the .so

objectes (there are only a 1/2 dozen or less in the whole build) and see if first the ifpServer
and gfe executables can be make to link/build. Then I would go back and see what needs to
be adjusted to link the shared objects.

Last edit: Mike Romberg 2019-01-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Scott Kehler - 2019-01-08
  
  Thanks for the suggestions. I tried replacing -shared with -c -fPIC and that seemed to link things properly.
  
  However, I have now been getting a lot of errors due to missing libraries. I assume this has something to do with differences in the compiler on mac vs. linux. Many of them were easy fixes by including the appropriate library, but some are tougher to figure out. Here's the latest error I encountered and am having a tough time solving:
  
  LogStream.C:149:33: error: no matching function for call to 'basename'
  static std::string leafOnly(basename(fullName.c_str()));
  ^~~~~~~~
  /usr/include/libgen.h:40:7: note: candidate function not viable: 1st argument ('const
  std::__1::basic_string<char, std::__1::char_traits\<char="">, std::__1::allocator\<char> >::value_type '
  (aka 'const char ')) would lose const qualifier
  char basename(char );
  ^
  LogStream.C:250:54: error: 'this' argument to member function 'getProcName' has type 'const logs::LogStream',
  but function is not marked const
  returnPath += LogStream::getProcName();
  ^~~~~~~~~~~
  LogStream.C:146:31: note: 'getProcName' declared here
  std::string &logs::LogStream::getProcName(bool useFullPath)</char></char,>
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mike Romberg - 2019-01-08

The man page here on linux (for the gnu C library) mentions two versions of basename. The first and default one is POSIX and has a signature:

char basename(char )

The second is a GNU version never modifies it's argument and reads:

char basenae(const char )

With the gnu C library it looks like you get the gnu version if you don't include libgen.h

The compiler is of course finding the POSIX version on osx and complaining about the const problem. Which is good because if it compiled it it would segfault at runtime. FreeBSD (which rumor has it osx is loosely based on) uses the gnu version of this. However it appears osx uses the clunkier POSIX one. So, the code will probably need to be patched by copying the fullName string into a char buffer/array and passing that array into basename. I would first check the manpages/docs on osx and see if it too has a second version (the const char * one) that can be enabled in some way. Most modern unices seem to be heading this way as it is cleaner. Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Scott Kehler - 2019-01-08
  
  It seems that on mac there was a second basename called basename_r, but it took two arguments. Instead I followed your advice of copying fullName into a char and that seemed to work.
  
  I got a few more errors after that which were fixed relatively easily. My C/C++ skills are pretty much zero, but I am somewhat knowledgeable in other languages so I am slowing working through the errors....but now came across another that I can't figure out:
  
  clang: warning: argument unused during compilation: '-L/Library/Frameworks/Python.framework/Versions/3.6/lib' [-Wunused-command-line-argument]
  LogEnv.C:127:14: error: no viable overloaded '='
  rval = buf;
  ~~~~ ^ ~~~
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/experimental/optional:351:15: note:
  candidate function not viable: no known conversion from 'char ' to
  'std::experimental::fundamentals_v1::nullopt_t' for 1st argument
  optional& operator=(nullopt_t) noexcept
  ^
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/experimental/optional:363:5: note:
  candidate function not viable: no known conversion from 'char ' to 'const
  std::experimental::fundamentals_v1::optional<std::__1::basic_string\<char> >' for 1st argument
  operator=(const optional& __opt)
  ^
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/experimental/optional:383:5: note:
  candidate function not viable: no known conversion from 'char *' to
  'std::experimental::fundamentals_v1::optional<std::__1::basic_string\<char> >' for 1st argument
  operator=(optional&& __opt)
  ^
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/experimental/optional:414:5: note:
  candidate template ignored: requirement 'is_same<typename remove_reference\<char="" *&="">::type, value_type>::value' was not satisfied [with _Up = char *&]
  operator=(_Up&& __v)
  ^
  1 error generated.
  make[3]: *** [LogEnv.o] Error 1
  make[2]: *** [all] Error 2
  make[1]: *** [logStream] Error 2
  make: *** [libs] Error 2</typename></std::__1::basic_string\<char></std::__1::basic_string\<char>
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mike Romberg - 2019-01-09

Looks like the version of clang you are using does not implement that experimental new class. The clang in fedora 27+ does. Luckily, LogEnv.C is not really being used. So, you can simply remove it from the liblogStream.a in the Makefile and move along.

I have built the gfe with clang. But I don't use it all the time. Since you are already trying to build the gfe on a platform it has not been run on in over a decade, it might be a good idea to use gcc (version 7 or 8) first. I don't really know much about how the recent clang versions support the newer c++11, c++14 standards and what switches may need to be tossed at clang to make things work. Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Scott Kehler - 2019-01-09
  
  Continuing to progress...here is the latest error I can't get past.
  
  ColorTableWriter.C:68:18: error: no member named 'sync' in 'netCDF::NcFile'
  _ncFile->sync();
  ~~~~~~~ ^
  1 error generated.
  make[2]: *** [ColorTableWriter.o] Error 1
  make[1]: *** [all] Error 2
  make: *** [ifpServer] Error 2
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mike Romberg - 2019-01-10

There are at least two netcdf c++ libraries. The gfe used to use the really ancient one which is what I suspect you may have installed. I've ported it over to the newer netcdf-4 one which uses some more modern c++ featues (and is supported by the netcdf folks).

On fedora, the package claims to be:

rpm --info -qf /usr/include/netcdf
Name : netcdf-cxx4-devel
Version : 4.3.0

I have no idea if this is pre-built/packaged for osx. But the download page seems to be here:

https://www.unidata.ucar.edu/downloads/netcdf/index.jsp
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Scott Kehler - 2019-01-11

Your netcdf suggestion was correct. I needed to install netcdf4-c++.

Getting another linking error now - not sure what's up with this one:

/usr/bin/clang++ -std=c++14 -stdlib=libc++ -L/Library/Frameworks/Python.framework/Versions/3.6/lib -lpython3.6m -lpthread -I/Library/Frameworks/Python.framework/Versions/3.6/include/python3.6m -I/usr/local/Cellar/libxml++/2.40.1/include/libxml++-2.6 -I/usr/local/Cellar/glibmm/2.46.3/include/glibmm-2.4 -I/usr/local/Cellar/glibmm/2.46.3/lib/glibmm-2.4/include -I/usr/local/Cellar/glib/2.46.2/include/glib-2.0 -I/usr/local/Cellar/glib/2.46.2/lib/glib-2.0/include -I/usr/local/Cellar/libxml++/2.40.1/lib/libxml++-2.6/include -I/usr/X11/include -v -Wl,-export_dynamic -Wall -Wextra -Wno-missing-braces -O3 -pipe -g -o ifpServer ifpServer_version.o ifpServer.o IFPDaemon.o IFPConnection.o IFPServer.o Server.o ParmStorageInfo.o AreaStorageInfo.o StorageInfo.o GridDatabase.o VGridDatabase.o TopoDatabase.o IFPGridDatabase.o D2DGridDatabase.o RunBackgroundTask.o NetCDFUtils.o D2DDataDir.o D2DSatParm.o D2DSatDatabase.o D2DFile.o NetcdfDatabase.o TimeInfo.o GridParm.o GridParmMgr.o LockDatabase.o LockMgr.o IFPServerConfig.o GridDbConfig.o ProcessTopography.o TopoMgr.o ReferenceMgr.o SampleMgr.o MapManager.o Attribute.o MapInfo.o TextFileMgr.o ColorSpectrumMgr.o ColorTableReader.o ColorTableWriter.o PathMgr.o RunInit.o SendISCMgr.o DTMTopo.o -L/Users/scottkehler/gfed-code/libs/ifpData -lifpData -L/Users/scottkehler/gfed-code/libs/support -lsupport -L/Users/scottkehler/gfed-code/libs/pyInter -lsupIntr -L/Users/scottkehler/gfed-code/libs/foundation -lfoundation -L/Users/scottkehler/gfed-code/libs/logStream -llogStream -lnetcdf_c++4 -lnetcdf -lpython3.6m -ldl -framework CoreFoundation -lz
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.13.0 -o ifpServer -L/Library/Frameworks/Python.framework/Versions/3.6/lib -L/Users/scottkehler/gfed-code/libs/ifpData -L/Users/scottkehler/gfed-code/libs/support -L/Users/scottkehler/gfed-code/libs/pyInter -L/Users/scottkehler/gfed-code/libs/foundation -L/Users/scottkehler/gfed-code/libs/logStream -lpython3.6m -lpthread -export_dynamic ifpServer_version.o ifpServer.o IFPDaemon.o IFPConnection.o IFPServer.o Server.o ParmStorageInfo.o AreaStorageInfo.o StorageInfo.o GridDatabase.o VGridDatabase.o TopoDatabase.o IFPGridDatabase.o D2DGridDatabase.o RunBackgroundTask.o NetCDFUtils.o D2DDataDir.o D2DSatParm.o D2DSatDatabase.o D2DFile.o NetcdfDatabase.o TimeInfo.o GridParm.o GridParmMgr.o LockDatabase.o LockMgr.o IFPServerConfig.o GridDbConfig.o ProcessTopography.o TopoMgr.o ReferenceMgr.o SampleMgr.o MapManager.o Attribute.o MapInfo.o TextFileMgr.o ColorSpectrumMgr.o ColorTableReader.o ColorTableWriter.o PathMgr.o RunInit.o SendISCMgr.o DTMTopo.o -lifpData -lsupport -lsupIntr -lfoundation -llogStream -lnetcdf_c++4 -lnetcdf -lpython3.6m -ldl -framework CoreFoundation -lz -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/lib/darwin/libclang_rt.osx.a
ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
Undefined symbols for architecture x86_64:
"IFPServer::gridsPurge()", referenced from:
IFPDaemon::dbAndGridPurgeCheck(AbsTime const&) const in IFPDaemon.o
"IFPServer::preenDrafts(AbsTime const&)", referenced from:
IFPDaemon::periodicTasks() in IFPDaemon.o
"IFPServer::startServices()", referenced from:
IFPDaemon::runServer(bool) in IFPDaemon.o
"IFPServer::dbVersionPurge()", referenced from:
IFPDaemon::dbAndGridPurgeCheck(AbsTime const&) const in IFPDaemon.o
"IFPServer::sendMessageToUser(std::__1::basic_string<char, std::__1::char_traits\<char="">, std::__1::allocator\<char> > const&, int, std::__1::basic_string<char, std::__1::char_traits\<char="">, std::__1::allocator\<char> > const&)", referenced from:
IFPDaemon::periodicTasks() in IFPDaemon.o
"IFPServer::iscDataHasBeenSent(std::__1::vector<parmid, std::__1::allocator\<parmid=""> > const&, TimeRange const&)", referenced from:
SendISCMgr::dequeue() in SendISCMgr.o
"IFPServer::backgroundTaskTableUpdated(std::__1::vector<processstatus, std::__1::allocator\<processstatus=""> > const&, WsId const&)", referenced from:
RunBackgroundTask::queueTask(WsId const&, std::__1::basic_string<char, std::__1::char_traits\<char="">, std::__1::allocator\<char> > const&, std::__1::basic_string<char, std::__1::char_traits\<char="">, std::__1::allocator\<char> > const&) in RunBackgroundTask.o
RunBackgroundTask::dequeue(WsId const&) in RunBackgroundTask.o
RunBackgroundTask::forceStart(WsId const&, unsigned long) in RunBackgroundTask.o
RunBackgroundTask::taskFinished(RunBackgroundTask::Tasks&, WsId const&) in RunBackgroundTask.o
"IFPServer::scanD2D(bool)", referenced from:
IFPDaemon::runServer(bool) in IFPDaemon.o
IFPDaemon::periodicTasks() in IFPDaemon.o
IFPDaemon::scanD2D(AbsTime const&) const in IFPDaemon.o
"IFPServer::IFPServer(IFPServerConfig const&, GridParmMgr, LockMgr, TopoMgr, SampleMgr, ReferenceMgr, MapManager, TextFileMgr, ColorSpectrumMgr, SendISCMgr, RunBackgroundTask)", referenced from:
IFPDaemon::createServer(bool) in IFPDaemon.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [ifpServer] Error 1
make[1]: *** [all] Error 2
make: *** [ifpServer] Error 2</char></char,></char></char,></processstatus,></parmid,></char></char,></char></char,>

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Scott Kehler - 2019-01-11

I added a -c flag and that seemed to solve the above linking issue...

I managed to get all the way through the "make" process. However, when I did "make install" I found out the ifpServer/ifpServer directory was not created - presumably there was some issue with the ifpServer compile process. It appears the gfe was built properly.

Any suggestions on where to look for tracking down why ifpServer wasn't built?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Scott Kehler - 2019-01-12

Update:

Looks like when I added the -c flag that actually caused linking to be skipped? Which caused the ifpServer files not be used and therefore the executable didn't build - at least that's my basic understanding. If I remove the -c flag I get the following error, which I think is the one that needs to be solved in order to build ifpServer:

/usr/bin/clang++ -std=c++14 -stdlib=libc++ -L/Library/Frameworks/Python.framework/Versions/3.6/lib -lpython3.6m -lpthread -I/Library/Frameworks/Python.framework/Versions/3.6/include/python3.6m -I/usr/local/Cellar/libxml++/2.40.1/include/libxml++-2.6 -I/usr/local/Cellar/glibmm/2.46.3/include/glibmm-2.4 -I/usr/local/Cellar/glibmm/2.46.3/lib/glibmm-2.4/include -I/usr/local/Cellar/glib/2.46.2/include/glib-2.0 -I/usr/local/Cellar/glib/2.46.2/lib/glib-2.0/include -I/usr/local/Cellar/libxml++/2.40.1/lib/libxml++-2.6/include -I/usr/X11/include -I/usr/local/Cellar/ -I/opt/local/include -v -stdlib=libc++ -Xlinker -export_dynamic -Wall -Wextra -Wno-missing-braces -O3 -pipe -g -o ifpServer ifpServer_version.o ifpServer.o IFPDaemon.o IFPConnection.o IFPServer.o Server.o ParmStorageInfo.o AreaStorageInfo.o StorageInfo.o GridDatabase.o VGridDatabase.o TopoDatabase.o IFPGridDatabase.o D2DGridDatabase.o RunBackgroundTask.o NetCDFUtils.o D2DDataDir.o D2DSatParm.o D2DSatDatabase.o D2DFile.o NetcdfDatabase.o TimeInfo.o GridParm.o GridParmMgr.o LockDatabase.o LockMgr.o IFPServerConfig.o GridDbConfig.o ProcessTopography.o TopoMgr.o ReferenceMgr.o SampleMgr.o MapManager.o Attribute.o MapInfo.o TextFileMgr.o ColorSpectrumMgr.o ColorTableReader.o ColorTableWriter.o PathMgr.o RunInit.o SendISCMgr.o DTMTopo.o -L/Users/scottkehler/gfed-code/libs/ifpData -lifpData -L/Users/scottkehler/gfed-code/libs/support -lsupport -L/Users/scottkehler/gfed-code/libs/pyInter -lsupIntr -L/Users/scottkehler/gfed-code/libs/foundation -lfoundation -L/Users/scottkehler/gfed-code/libs/logStream -llogStream -L/Users/scottkehler/Desktop/netcdf/lib -lnetcdf_c++4 -lnetcdf -lpython3.6m -ldl -framework CoreFoundation -L/Users/scottkehler/miniconda2/pkgs/zlib-1.2.8-0/lib -lz
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.14.0 -o ifpServer -L/Library/Frameworks/Python.framework/Versions/3.6/lib -L/Users/scottkehler/gfed-code/libs/ifpData -L/Users/scottkehler/gfed-code/libs/support -L/Users/scottkehler/gfed-code/libs/pyInter -L/Users/scottkehler/gfed-code/libs/foundation -L/Users/scottkehler/gfed-code/libs/logStream -L/Users/scottkehler/Desktop/netcdf/lib -L/Users/scottkehler/miniconda2/pkgs/zlib-1.2.8-0/lib -lpython3.6m -lpthread -export_dynamic ifpServer_version.o ifpServer.o IFPDaemon.o IFPConnection.o IFPServer.o Server.o ParmStorageInfo.o AreaStorageInfo.o StorageInfo.o GridDatabase.o VGridDatabase.o TopoDatabase.o IFPGridDatabase.o D2DGridDatabase.o RunBackgroundTask.o NetCDFUtils.o D2DDataDir.o D2DSatParm.o D2DSatDatabase.o D2DFile.o NetcdfDatabase.o TimeInfo.o GridParm.o GridParmMgr.o LockDatabase.o LockMgr.o IFPServerConfig.o GridDbConfig.o ProcessTopography.o TopoMgr.o ReferenceMgr.o SampleMgr.o MapManager.o Attribute.o MapInfo.o TextFileMgr.o ColorSpectrumMgr.o ColorTableReader.o ColorTableWriter.o PathMgr.o RunInit.o SendISCMgr.o DTMTopo.o -lifpData -lsupport -lsupIntr -lfoundation -llogStream -lnetcdf_c++4 -lnetcdf -lpython3.6m -ldl -framework CoreFoundation -lz -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/lib/darwin/libclang_rt.osx.a
Undefined symbols for architecture x86_64:
"IFPServer::gridsPurge()", referenced from:
IFPDaemon::dbAndGridPurgeCheck(AbsTime const&) const in IFPDaemon.o
"IFPServer::preenDrafts(AbsTime const&)", referenced from:
IFPDaemon::periodicTasks() in IFPDaemon.o
"IFPServer::startServices()", referenced from:
IFPDaemon::runServer(bool) in IFPDaemon.o
"IFPServer::dbVersionPurge()", referenced from:
IFPDaemon::dbAndGridPurgeCheck(AbsTime const&) const in IFPDaemon.o
"IFPServer::sendMessageToUser(std::__1::basic_string<char, std::__1::char_traits\<char="">, std::__1::allocator\<char> > const&, int, std::__1::basic_string<char, std::__1::char_traits\<char="">, std::__1::allocator\<char> > const&)", referenced from:
IFPDaemon::periodicTasks() in IFPDaemon.o
"IFPServer::iscDataHasBeenSent(std::__1::vector<parmid, std::__1::allocator\<parmid=""> > const&, TimeRange const&)", referenced from:
SendISCMgr::dequeue() in SendISCMgr.o
"IFPServer::backgroundTaskTableUpdated(std::__1::vector<processstatus, std::__1::allocator\<processstatus=""> > const&, WsId const&)", referenced from:
RunBackgroundTask::queueTask(WsId const&, std::__1::basic_string<char, std::__1::char_traits\<char="">, std::__1::allocator\<char> > const&, std::__1::basic_string<char, std::__1::char_traits\<char="">, std::__1::allocator\<char> > const&) in RunBackgroundTask.o
RunBackgroundTask::dequeue(WsId const&) in RunBackgroundTask.o
RunBackgroundTask::forceStart(WsId const&, unsigned long) in RunBackgroundTask.o
RunBackgroundTask::taskFinished(RunBackgroundTask::Tasks&, WsId const&) in RunBackgroundTask.o
"IFPServer::scanD2D(bool)", referenced from:
IFPDaemon::runServer(bool) in IFPDaemon.o
IFPDaemon::periodicTasks() in IFPDaemon.o
IFPDaemon::scanD2D(AbsTime const&) const in IFPDaemon.o
"IFPServer::IFPServer(IFPServerConfig const&, GridParmMgr, LockMgr, TopoMgr, SampleMgr, ReferenceMgr, MapManager, TextFileMgr, ColorSpectrumMgr, SendISCMgr, RunBackgroundTask)", referenced from:
IFPDaemon::createServer(bool) in IFPDaemon.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [ifpServer] Error 1
make[1]: *** [all] Error 2
make: *** [ifpServer] Error 2</char></char,></char></char,></processstatus,></parmid,></char></char,></char></char,>

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mike Romberg - 2019-01-23

Hmm... The missing symbols from the IFPServer class should be there as the IFPServer.o object file is clearly on the link line. You do have some other extra include (-I) and library (-L) stuff there which I assume you added in to the CXX variable. But I don't think they are the trouble.

I'm not all that familiar with the osx linker and it is possible that there is some wierd stuff going on with it and the python link flags (-export-dynamic). It is very possible that a somewhat different linker flag is needed on osx to support the embeded python interpreter. Possibly also the stdlib thing is not helping as well.

For starters, lets see what is going on with IFPServer.o. Could you rebuild that object file and post what the compile line looks like? I would like to see if there are any unusual flags or options when it was built. In the meantime, I will rebuild my gfe with clang here on linux. It has been a while. I can at least verify that things work with clang on linux. Then we may need to experiment with what makes python happy linking on osx.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Scott Kehler - 2019-01-23
  
  I tried the rebuild and I think this is the output you're looking for. I saved the output of the entire build and attached it here for reference (build was done with the -v flag to provide more detail).
  
  FYI I recall you saying earlier that I should try building with gcc rather than clang. Howver, I believe on mac gcc automatically uses clang anyway. There might be a way to actually use gcc on mac, but that's above my pay grade.
  
  /usr/bin/clang++ -std=c++14 -stdlib=libc++ -L/Library/Frameworks/Python.framework/Versions/3.6/lib -lpython3.6m -lpthread -I/Library/Frameworks/Python.framework/Versions/3.6/include/python3.6m -I/usr/local/Cellar/libxml++/2.40.1/include/libxml++-2.6 -I/usr/local/Cellar/glibmm/2.46.3/include/glibmm-2.4 -I/usr/local/Cellar/glibmm/2.46.3/lib/glibmm-2.4/include -I/usr/local/Cellar/glib/2.46.2/include/glib-2.0 -I/usr/local/Cellar/glib/2.46.2/lib/glib-2.0/include -I/usr/local/Cellar/libxml++/2.40.1/lib/libxml++-2.6/include -I/usr/X11/include -I/usr/local/Cellar/ -I/opt/local/include -v -I/Users/scottkehler/gfed-code/libs/ifpData/include -I/Users/scottkehler/gfed-code/libs/support -I/Users/scottkehler/gfed-code/libs/foundation -I/Users/scottkehler/gfed-code/libs/logStream -Wp,-MD,.ifpServer.o.d -Wall -Wextra -Wno-missing-braces -O3 -pipe -g -c ifpServer.C -o ifpServer.o
  Apple LLVM version 10.0.0 (clang-1000.11.45.5)
  Target: x86_64-apple-darwin18.2.0
  Thread model: posix
  InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
  clang: warning: -lpython3.6m: 'linker' input unused [-Wunused-command-line-argument]
  clang: warning: -lpthread: 'linker' input unused [-Wunused-command-line-argument]
  clang: warning: argument unused during compilation: '-L/Library/Frameworks/Python.framework/Versions/3.6/lib' [-Wunused-command-line-argument]
  "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.14.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name ifpServer.C -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-cpu penryn -dwarf-column-info -debug-info-kind=standalone -dwarf-version=4 -debugger-tuning=lldb -target-linker-version 409.12 -v -coverage-notes-file /Users/scottkehler/gfed-code/ifpServer/ifpServer.gcno -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0 -dependency-file .ifpServer.o.d -skip-unused-modulemap-deps -MT ifpServer.o -sys-header-deps -I /Library/Frameworks/Python.framework/Versions/3.6/include/python3.6m -I /usr/local/Cellar/libxml++/2.40.1/include/libxml++-2.6 -I /usr/local/Cellar/glibmm/2.46.3/include/glibmm-2.4 -I /usr/local/Cellar/glibmm/2.46.3/lib/glibmm-2.4/include -I /usr/local/Cellar/glib/2.46.2/include/glib-2.0 -I /usr/local/Cellar/glib/2.46.2/lib/glib-2.0/include -I /usr/local/Cellar/libxml++/2.40.1/lib/libxml++-2.6/include -I /usr/X11/include -I /usr/local/Cellar/ -I /opt/local/include -I /Users/scottkehler/gfed-code/libs/ifpData/include -I /Users/scottkehler/gfed-code/libs/support -I /Users/scottkehler/gfed-code/libs/foundation -I /Users/scottkehler/gfed-code/libs/logStream -stdlib=libc++ -O3 -Wall -Wextra -Wno-missing-braces -std=c++14 -fdeprecated-macro -fdebug-compilation-dir /Users/scottkehler/gfed-code/ifpServer -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fencode-extended-block-signature -fobjc-runtime=macosx-10.14.0 -fcxx-exceptions -fexceptions -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o ifpServer.o -x c++ ifpServer.C
  clang -cc1 version 10.0.0 (clang-1000.11.45.5) default target x86_64-apple-darwin18.2.0
  ignoring nonexistent directory "/usr/include/c++/v1"
  
  include "..." search starts here:
  
  include <...> search starts here:
  
  /Library/Frameworks/Python.framework/Versions/3.6/include/python3.6m
  /usr/local/Cellar/libxml++/2.40.1/include/libxml++-2.6
  /usr/local/Cellar/glibmm/2.46.3/include/glibmm-2.4
  /usr/local/Cellar/glibmm/2.46.3/lib/glibmm-2.4/include
  /usr/local/Cellar/glib/2.46.2/include/glib-2.0
  /usr/local/Cellar/glib/2.46.2/lib/glib-2.0/include
  /usr/local/Cellar/libxml++/2.40.1/lib/libxml++-2.6/include
  /usr/X11/include
  /usr/local/Cellar
  /opt/local/include
  /Users/scottkehler/gfed-code/libs/ifpData/include
  /Users/scottkehler/gfed-code/libs/support
  /Users/scottkehler/gfed-code/libs/foundation
  /Users/scottkehler/gfed-code/libs/logStream
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
  /usr/local/include
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/include
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
  /usr/include
  /System/Library/Frameworks (framework directory)
  /Library/Frameworks (framework directory)
  End of search list.
  
  gfe_make_output
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

When the link bombs, it is complaining about missing symbols that should be in the file IFPServer.o  (note the caps).  The file ifpServer.o has a similar name and mostly contains the main() function for the server.  The meat and taters is in the file with the capital letters.

  However, I did not see this file being compiled at all when I searched your gfe_make_output.   So, I have a few questions and things for you to try.

    Are you using gnu make?  If not, you really, really should be as I've never tested these new makefiles with any other make variant.  And the odds are good that I may be using some gnumake specific things.   I know some BSD makes support many of the features of gnu make.   But I have never tested them with a gfe build.

      A "clean" build should be (from the TOP directory [gfe and ifpServer are subdirectories of the TOP directory):

      make clean
      make links
        make

          That should (assuming you are using gnu make) rebuild everything.   I have hopes that IFPServer.o was the result of an earlier build with incompatable flags or something.  That would explain the link failures.  Rebuilding everything (including it) may fix things.

Scott Kehler - 2019-01-23

I also noticed that IFPServer.o didn't seem to present anywhere - so that seems like it's at least part of the issue here.

I tried man make in the terminal and it appears to show that I am using GNU make:

NAME
make - GNU make utility to maintain groups of program

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Scott Kehler - 2019-02-14

After much fighting with the compilation process, I decided to give up. I did sucessfully get the GFE client to build, but when I launched it I only got a black screen. I could activate the menus by clicking on the appropriate part of the window, but everything else was black, so it was obviously unuseable. I am not sure if this is an issue with tkinter or X11 or something else, but either way that's the farthest I got.

Rather than continuing to fight with the compilation process, I found a clever way to run the GFE on mac using docker. Here are the steps to running GFE on mac using docker:

1) Install Xquartz (if not already installed)
2) Install Docker (if not already installed)
3) Install Homebrew (if not already installed)
4) brew install socat
5) Create a new directory where you will create a new docker image (it can be called anything). In that directory, put the attached docker file.
6) When in the above directory, run: docker build --tag=gfe .
7) The Dockerfile will resolve all the dependencies and download/make the GFE

Once you have done all of the above, the GFE is installed and ready to use. To use it, do the following:
1) Run in terminal: socat TCP-LISTEN:6000,reuseaddr,fork UNIX-CLIENT:\"$DISPLAY\" (this allows you to create an Xquartz window to view the GFE from within docker).
2) docker run -e DISPLAY={Your LAN IP}:0 --env host={GFE host address} --env user={your username} -v /tmp/.X11-unix:/tmp/.X11-unix/ gfe

Note this assumes you have access to a GFE server somewhere (enter the server ip in the GFE host address section). If you want to run the ifpServer on mac as well, you would need to modify the last line of the Dockerfile to activate the server, then run the GFE client after.

Overall, the GFE seems to perform very well even when running with Docker. The only lag is when new weather elements are added or grids are populated because all the data in my case is being pulled in from a remote server. I assume if you ran the ifpServer locally, these lags would be greatly reduced.

Dockerfile

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Crist Cace - 2019-02-24

Edit: What GFE server did you use to run gfe properly?

Last edit: Crist Cace 2019-02-24

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Scott Kehler - 2019-02-24
  
  I run the ifpServer on an AWS EC2 instance which I setup as fedora 28. I then connect to the EC2 instance using the GFE client on my mac.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mike Romberg - 2019-02-28

I'm guessing you may be reasonably close to a working native gfe Scott. When I did it years ago, I remember something along the lines of Tcl/Tk Tkinter on osx having both native and X11 versions. The gfe for sure requires the X11 versions. The widgets (buttons, scrollbars, menus etc) would be fine with native widgets. However the gfe's drawing code is all X11 and asks the Tk frame widget to adopt an X11 window to display them. This may change when I get around to converting these graphics to opengl or something. But for now, make sure the Tkinter package has X11 support.

Back when I had things running on osx, the gfe (client) worked fine. The server almost worked fine except that there was a freebsd bug in the C library apple would not fix for some reason. So, I know that it was possible at one point.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mac OSX Support

View and edit grids of meteorological values

Milestone

Searches

Help

#19 Mac OSX Support

Discussion

include "..." search starts here:

include <...> search starts here: