"Operation not permitted" occurs even with sudo

sudo bash ./build.sh

The build fails with message:
Run cmake -DADDRESS_SANITIZER=ON /mnt/d/gnsstk ##########################

cmake -DADDRESS_SANITIZER=ON /mnt/d/gnsstk

make all -j 6
CMake Error: failed to create symbolic link 'libgnsstk.so.14': Operation not permitted
CMake Error: cmake_symlink_library: System Error: Operation not permitted
CMake Error: failed to create symbolic link 'libgnsstk.so': Operation not permitted
CMake Error: cmake_symlink_library: System Error: Operation not permitted
make[2]: *** [CMakeFiles/gnsstk.dir/build.make:5266: libgnsstk.so.14.0.0] Error 1
make[2]: *** Deleting file 'libgnsstk.so.14.0.0'
make[1]: *** [CMakeFiles/Makefile2:115: CMakeFiles/gnsstk.dir/all] Error 2
make: *** [Makefile:156: all] Error 2

Error 2 :-(
See /mnt/d/gnsstk/build/DESKTOP-1DRKFVR-v14.0.0/Testing/Temporary/LastTest.log for detailed test log
See /mnt/d/gnsstk/build/DESKTOP-1DRKFVR-v14.0.0/build.log for detailed build log

This problem appeared with version 14.0
gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)
Python 3.10.6

When I try to build GNSS toolkit 13.4.0 on openSUSE, I get the following error after cmake command:

CMake Error at /usr/share/cmake/Modules/CMakePackageConfigHelpers.cmake:265 (message):
 Variable PYTHON_VERSION_MAJOR does not exist
 Call Stack (most recent call first):
   CMakeLists.txt:248 (configure_package_config_file)
 
 
 -- Configuring incomplete, errors occurred!
 See also "/home/abuild/rpmbuild/BUILD/gnsstk-13.4.0/build/CMakeFiles/CMakeOutput.log".
 error: Bad exit status from /var/tmp/rpm-tmp.Q3xc4O (%build)

the same error is when I use build.sh script.
Is something missing? Do I need to specify Python version manuaally?

According to the standard, if the xmitTime is set to .9999+e09, then it should be treated as invalid/unknown. However, the library doesn't do this and uses this value as if it were proper.

The following call to fixTimeGPS() then destroys navOut.xmitTime by adding this invalid value to a GPS week nr.:

Apparently, this one place where the invalid value destroys things could get easily fixed by treating the invalid value as 0, but I'm not sure whether there are other places where it could make problems.

One of the problematic RINEX v3 files is e.g. this one: https://igs.bkg.bund.de/root_ftp/MGEX/BRDC/2024/001/BRDC00WRD_S_20240010000_01D_MN.rnx.gz . E.g. the very first nav message:

E08 2023 12 31 23 50 00-2.009316231124e-04-5.940137270954e-12 0.000000000000e+00
     1.500000000000e+01-1.201562500000e+02 2.852261665290e-09-3.006433072931e+00
    -5.470588803291e-06 1.602121628821e-04 8.979812264442e-06 5.440613040924e+03
     8.580000000000e+04-8.195638656616e-08 4.684350206789e-01-9.313225746155e-09
     9.662984159677e-01 1.517812500000e+02 7.945787833385e-01-5.399510625576e-09
    -2.142946405177e-12 5.170000000000e+02 2.295000000000e+03 0.000000000000e+00
     3.120000000000e+00 0.000000000000e+00-3.725290298462e-09-4.423782229424e-09
     9.999000000000e+08   

You can see the 9.999000000000e+08 in the very last position. This is what makes problems.

Reproducer:

gnsstk::NavLibrary lib;
gnsstk::NavDataFactoryPtr fac = std::make_shared<gnsstk::RinexNavDataFactory>();
fac->addDataSource("BRDC00WRD_S_20240010000_01D_MN.rnx");
lib.addFactory(fac);
std::cout << gnsstk::printTime(gnsstk::CivilTime(lib.getInitialTime()), "%Y-%m-%d %H:%M:%f") << " --- "
          << gnsstk::printTime(gnsstk::CivilTime(lib.getFinalTime()), "%Y-%m-%d %H:%M:%f") << std::endl;

Initial time is wrongly in year 2055 and final time is also weird:

2055-8-30 22:0:0.000000 --- 2023-12-25 4:0:0.000000

Lookup a xvt for SEM or YUMA NavDataFactory and no entries are found because it doesn't correct for weeknumber rollover

https://en.cppreference.com/w/cpp/utility/functional/binary_function

The SP3 format says that SP3 ephemeris files should end with "EOF". However, the gnsstk code mentions being tolerant of a missing EOF.

Using the approach in SP3_T.cpp for reading a file, you will miss the last record if the file is missing the EOF.

Would this be considered a bug, or is gnsstk not intended to properly read files which are missing an EOF?

FFStream::init calls close. If a file is not open, this close call fails. In a default configuration this is not a problem. However, if you set the stream to throw exceptions on fail, then you get an exception when opening a file.

The solutions is to change the code to:

if(is_open())
   close();

I am new to gnsstk and can't find the api document.
Could you tell me where I can find the api documents for gnsstk?
Thank you!

I have problem with building gnsstk on openSUSE Tumblewwed. The build fails with this message:

/home/abuild/rpmbuild/BUILD/gnsstk-14.0.0/core/lib/TimeHandling/CommonTime.hpp:95: Error: Syntax error in input(3).
make[2]: *** [swig/CMakeFiles/_ClockModel.dir/build.make:79: swig/CMakeFiles/_ClockModel.dir/ClockModelPYTHON_wrap.cxx] Error 1
make[2]: Leaving directory '/home/abuild/rpmbuild/BUILD/gnsstk-14.0.0/build'
make[1]: *** [CMakeFiles/Makefile2:595: swig/CMakeFiles/_ClockModel.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

This problem appeared with version (tag) 13.7.0 and is present in current release 14.0.0.
openSUSE Tumbleweed uses following tools:
gcc-c++ 12.2
python3 3.10.9
swig 4.1.1

For openSUSE Leap 15.4 build is OK

I can get PrintTime to write a time with 60 in the seconds field, instead of rolling over to 1 minute and 0 seconds.

>>> import gnsstk
>>> ct = gnsstk.CommonTime()
>>> ct = ct.set(2459313,59,0.9999999999)
>>> print(gnsstk.printTime(ct,'%02d-%b-%Y %02H:%02M:%012.9f %P'))
08-Apr-2021 00:00:60.000000000 UNK

Due to the setting of -Werror=return-type in the compiler flags below:

the project won't compile on my Linux using Cmake due to no return statement placed before the bracket here:

Here is the warning treated as error that gcc 7.5.0 issues:

[ 30%] Building CXX object CMakeFiles/gnsstk.dir/core/lib/GNSSCore/SatMetaDataStore.cpp.o
/home/coezmaden/Repositories/gnsstk/core/lib/GNSSCore/RefFrameRlz.cpp: In function ‘gnsstk::RefFrameRlz gnsstk::getRefFrameRlz(gnsstk::RefFrameSys, const gnsstk::CommonTime&)’:
/home/coezmaden/Repositories/gnsstk/core/lib/GNSSCore/RefFrameRlz.cpp:177:4: error: control reaches end of non-void function [-Werror=return-type]
    }
    ^

Can be a potential easy fix by adding a return of an unknown reference frame RefFrameRlz::Unknown as I have done in my fork: 3f332d5
Should be tested for unwanted changes to the logic of the function.

Hi guys,

I wrote a small application in C++ using GPSTk. It worked using GPSTk from v3.0.0 up to 8.0.0. Now I’m trying to update the code to use GNSSTk, with backward compatibility, and with little effort I made it work up to v12.1.0.

However, I struggle in getting it working for v13.x, since the GPSEphemerisStore is now gone. Is there any new mechanism for that? Any documentation, example, or advice on how to migrate the code? Any help would be welcome.

Thanks in advance.

Thank you for the great library.

I wished to know about the roadmap of development. It seems like a lot of features from GPSTk are not yet implemented, and knowing the rough timeline would help us migrate from GPSTk to GNSSTk.

Thank you again!

I wang to use gnsstk in windows, but the website "http://www.gnsstk.org/bin/view/Documentation/BuildingGNSSTkUnderWindows" is not found.

Rinex3NavData::Rinex3NavData(const RinexNavData& rnd) does not copy Cuc with the other harmonic corrections:

      // perturbations
      Cus = rnd.Cus;
      Crc = rnd.Crc;
      Crs = rnd.Crs;
      Cic = rnd.Cic;
      Cis = rnd.Cis;

This impairs orbit calculations done from the sample data files arlm200*.15n.

I'm not sure if it is a problem, but when I open the link, Github returns 404

Visual Studio warns that setfill is nodiscard and the result is not being used here.

According to https://en.cppreference.com/w/cpp/io/manip/setfill, the result must be "streamed" into a stream to have an effect.

After the 14.3.0 release, the data submodule points to a non-existing commit. Probably a forgotten push to gnsstk-data? @gloppyuser