BIG difference in program and global variable size after compilation on MacOS vs Windows

Hello everyone, I'm trying to compile a program for an Arduino Nano board, but I'm running into some memory issues. The strange thing is that, when I compile it on Windows, the result is that the sketch takes up 65% of program storage space, and global variables use 102% of dynamic memory, but when I compile on MacOS, the sketch takes up 23% of program storage space, and global variables use 71% of dynamic memory.

What could cause such a huge difference in compilation sizes? They are both on the same branch of the same repo without any unsaved changes, and the libraries they use are the same version.

Thank you!

Edit: some more VERY INTERESTING INFO
I origninally had the following functions in my code:

uint8_t* createTelemetryPacketStr(float altitude, float temp, float voltage, double gpsLat, double gpsLng, float gpsAltitude, uint8_t gpsSats) {
   
   uint8_t buffer[12];
   unsigned char precision = 1, voltagePrecision = 2, latLngPrecision = 5, bufferPadding;
   
   itoa(TEAM_ID, telPacketString, 10);
   telPacketString[4] = ',';
   memcpy(telPacketString + 5, getMissionTimeString(12, 2, 3), 8);
   ...
   telPacketString[128] = 0;
   Serial.write(telPacketString, 128);
   return telPacketString;
}
...
void loop() {
        float temperature = sensorModule.readTemperature();
        float altitude = sensorModule.readAltitude();
        
        int voltageSensorValue = analogRead(A0);
        float voltage = voltageSensorValue * (5.0 / 1023.0); // Convert the analog reading (which goes from 0 - 1023) to a voltage (0 - 5V):
        
        double gpsLat = sensorModule.gps.location.lat();
        double gpsLng = sensorModule.gps.location.lng();
        double gpsAltitude = sensorModule.gps.altitude.meters();
        uint32_t gpsSatellites = sensorModule.gps.satellites.value();

        communicationModule.telemetryPacketQueue.add(createTelemetryPacketStr(altitude, temperature, voltage, gpsLat, gpsLng, gpsAltitude, gpsSatellites), 128);

And I moved all the variables into the createTelemetryPackageStr() function, removing them from the loop() function and sending a -1 alt value to the function:

uint8_t* createTelemetryPacketStr(float alt) {
    float altitude;
    if (alt == -1) {
      altitude = sensorModule.readAltitude();
    } else {
      altitude = alt;
    }

    float temp = sensorModule.readTemperature();
    int voltageSensorValue = analogRead(A0);
    float voltage = voltageSensorValue * (5.0 / 1023.0); // Convert the analog reading (which goes from 0 - 1023) to a voltage (0 - 5V):
    
    double gpsLat = sensorModule.gps.location.lat();
    double gpsLng = sensorModule.gps.location.lng();
    double gpsAltitude = sensorModule.gps.altitude.meters();
    uint32_t gpsSats = sensorModule.gps.satellites.value();
   
   uint8_t buffer[12];
   unsigned char precision = 1, voltagePrecision = 2, latLngPrecision = 5, bufferPadding;
   
   itoa(TEAM_ID, telPacketString, 10);
   telPacketString[4] = ',';
   memcpy(telPacketString + 5, getMissionTimeString(12, 2, 3), 8);
   ...
   telPacketString[128] = 0;
   Serial.write(telPacketString, 128);
   return telPacketString;
}

After this, the memory and program space on MacOS stays the same, but on Windows, the program size and the global variable sizes increased by 15% and 6% respectively.

Is the same board/ processor type selected ?

Yes, I'm compiling for Arduino Nano with ATmega328P processor on both IDEs.

This is a red flag. How big is telPacketString? Check your code for buffer overflows and other sources of undefined behavior.

Also, what does getMissionTimeString return? A pointer to char or bytes, presumably, but with what lifetime? Would it be more appropriate to pass telPacketString+5 to this function as an output parameter instead of copying the result?

Either way, you would expect the same compiler to generate the same output, even across operating systems. Check the Tools > Boards manager to make sure that you have the same version of the Arduino AVR Core installed on both machines.