The International Simutrans Forum

 

Author Topic: Incorporating changes from Standard  (Read 25872 times)

0 Members and 1 Guest are viewing this topic.

Offline freddyhayward

  • Devotee
  • *
  • Posts: 681
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #245 on: December 03, 2020, 12:41:05 AM »
Also, can I check whether you think that there is anything else that needs to be done before integrating the UI improvements together with the zstd work into the master branch?
I don't know whether the issue of many text colours such as for stop names having a dark bluish tint has been resolved.

Offline Ranran

  • Devotee
  • *
  • Posts: 1549
  • Languages: ja
Re: Incorporating changes from Standard
« Reply #246 on: December 03, 2020, 12:55:06 AM »
such as for stop names having a dark bluish tint has been resolved.
It looks like just a public player color, not a bug.
I think it's due to a change in the standard related to the theme. At least the same as standard.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20811
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #247 on: December 03, 2020, 01:09:00 PM »
TurfIt - thank you for checking that. It seems that I had omitted to modify the makefile to support ZSTD. I have now done this and installed zstd-dev, but I am afraid that I am now unable to compile on the Bridgewater-Brunel server. Attempting a basic Linux graphical client, I get the following errors:

Code: [Select]
root@438242:/usr/share/games/nightly/simutrans-experimental# make
expr: syntax error
===> CXX dataobj/loadsave.cc
dataobj/loadsave.cc:199:2: error: âZSTD_inBufferâ does not name a type
  ZSTD_inBuffer zin;
  ^
dataobj/loadsave.cc:200:2: error: âZSTD_outBufferâ does not name a type
  ZSTD_outBuffer zout;
  ^
dataobj/loadsave.cc: In member function âvoid loadsave_t::set_buffered(bool)â:
dataobj/loadsave.cc:248:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.src = NULL;
          ^
dataobj/loadsave.cc:249:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.size = 0;
          ^
dataobj/loadsave.cc:250:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.pos = 0;
          ^
dataobj/loadsave.cc:252:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.dst = fd->zbuff;
          ^
dataobj/loadsave.cc:253:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.size = LS_BUF_SIZE;
          ^
dataobj/loadsave.cc:254:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.pos = 0;
          ^
dataobj/loadsave.cc:257:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.src = fd->zbuff;
          ^
dataobj/loadsave.cc:258:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.size = LS_BUF_SIZE;
          ^
dataobj/loadsave.cc:259:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.pos = 0;
          ^
dataobj/loadsave.cc:261:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.dst = NULL;
          ^
dataobj/loadsave.cc:262:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.size = 0;
          ^
dataobj/loadsave.cc:263:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.pos = 0;
          ^
dataobj/loadsave.cc: In member function âbool loadsave_t::rd_open(const char*)â:
dataobj/loadsave.cc:370:7: error: âstruct file_descriptors_tâ has no member named âzinâ
   fd->zin.size = 0;
       ^
dataobj/loadsave.cc: In member function âbool loadsave_t::wr_open(const char*, loadsave_t::mode_t, int, const char*, const char*, const char*, const char*)â:
dataobj/loadsave.cc:557:37: error: âZSTD_c_compressionLevelâ was not declared in this scope
   ZSTD_CCtx_setParameter( fd->cctx, ZSTD_c_compressionLevel, level );
                                     ^
dataobj/loadsave.cc:557:68: error: âZSTD_CCtx_setParameterâ was not declared in this scope
   ZSTD_CCtx_setParameter( fd->cctx, ZSTD_c_compressionLevel, level );
                                                                    ^
dataobj/loadsave.cc: In member function âconst char* loadsave_t::close()â:
dataobj/loadsave.cc:672:8: error: âstruct file_descriptors_tâ has no member named âzinâ
    fd->zin.src = "";
        ^
dataobj/loadsave.cc:673:8: error: âstruct file_descriptors_tâ has no member named âzinâ
    fd->zin.size = 0;
        ^
dataobj/loadsave.cc:674:8: error: âstruct file_descriptors_tâ has no member named âzinâ
    fd->zin.pos = 0;
        ^
dataobj/loadsave.cc:676:8: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fd->zout.dst = fd->zbuff;
        ^
dataobj/loadsave.cc:677:8: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fd->zout.size = LS_BUF_SIZE;
        ^
dataobj/loadsave.cc:678:8: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fd->zout.pos = 0;
        ^
dataobj/loadsave.cc:682:9: error: âstruct file_descriptors_tâ has no member named âzoutâ
     fd->zout.pos = 0;
         ^
dataobj/loadsave.cc:683:49: error: âstruct file_descriptors_tâ has no member named âzoutâ
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                 ^
dataobj/loadsave.cc:683:62: error: âstruct file_descriptors_tâ has no member named âzinâ
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                              ^
dataobj/loadsave.cc:683:68: error: âZSTD_e_endâ was not declared in this scope
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                                    ^
dataobj/loadsave.cc:683:80: error: âZSTD_compressStream2â was not declared in this scope
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                                                ^
dataobj/loadsave.cc:684:17: error: âstruct file_descriptors_tâ has no member named âzoutâ
     fwrite( fd->zout.dst, 1, fd->zout.pos, fd->fp );
                 ^
dataobj/loadsave.cc:684:34: error: âstruct file_descriptors_tâ has no member named âzoutâ
     fwrite( fd->zout.dst, 1, fd->zout.pos, fd->fp );
                                  ^
dataobj/loadsave.cc: In member function âvoid loadsave_t::flush_buffer(int)â:
dataobj/loadsave.cc:860:26: error: âstruct file_descriptors_tâ has no member named âzoutâ
   gzwrite( fd->gzfp, fd->zout.dst, fd->zout.pos );
                          ^
dataobj/loadsave.cc:860:40: error: âstruct file_descriptors_tâ has no member named âzoutâ
   gzwrite( fd->gzfp, fd->zout.dst, fd->zout.pos );
                                        ^
dataobj/loadsave.cc:862:7: error: âstruct file_descriptors_tâ has no member named âzinâ
   fd->zin.src = ls_buf[ buf_num ];
       ^
dataobj/loadsave.cc:863:7: error: âstruct file_descriptors_tâ has no member named âzinâ
   fd->zin.size = buf_pos[ buf_num ];
       ^
dataobj/loadsave.cc:864:7: error: âstruct file_descriptors_tâ has no member named âzinâ
   fd->zin.pos = 0;
       ^
dataobj/loadsave.cc:866:15: error: âstruct file_descriptors_tâ has no member named âzinâ
   while(  fd->zin.pos < fd->zin.size  ) {
               ^
dataobj/loadsave.cc:866:29: error: âstruct file_descriptors_tâ has no member named âzinâ
   while(  fd->zin.pos < fd->zin.size  ) {
                             ^
dataobj/loadsave.cc:867:8: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fd->zout.pos = 0;
        ^
dataobj/loadsave.cc:868:48: error: âstruct file_descriptors_tâ has no member named âzoutâ
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
                                                ^
dataobj/loadsave.cc:868:61: error: âstruct file_descriptors_tâ has no member named âzinâ
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
                                                             ^
dataobj/loadsave.cc:868:67: error: âZSTD_e_continueâ was not declared in this scope
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
                                                                   ^
dataobj/loadsave.cc:868:83: error: âZSTD_compressStream2â was not declared in this scope
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
                                                                                   ^
dataobj/loadsave.cc:869:16: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fwrite( fd->zout.dst, 1, fd->zout.pos, fd->fp );
                ^
dataobj/loadsave.cc:869:33: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fwrite( fd->zout.dst, 1, fd->zout.pos, fd->fp );
                                 ^
dataobj/loadsave.cc: In member function âint loadsave_t::fill_buffer(int)â:
dataobj/loadsave.cc:966:7: error: âstruct file_descriptors_tâ has no member named âzoutâ
   fd->zout.dst = ls_buf[ buf_num ];
       ^
dataobj/loadsave.cc:967:7: error: âstruct file_descriptors_tâ has no member named âzoutâ
   fd->zout.size = LS_BUF_SIZE;
       ^
dataobj/loadsave.cc:968:7: error: âstruct file_descriptors_tâ has no member named âzoutâ
   fd->zout.pos = 0;
       ^
dataobj/loadsave.cc:972:16: error: âstruct file_descriptors_tâ has no member named âzinâ
    while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  ) {
                ^
dataobj/loadsave.cc:972:30: error: âstruct file_descriptors_tâ has no member named âzinâ
    while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  ) {
                              ^
dataobj/loadsave.cc:972:48: error: âstruct file_descriptors_tâ has no member named âzoutâ
    while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  ) {
                                                ^
dataobj/loadsave.cc:972:63: error: âstruct file_descriptors_tâ has no member named âzoutâ
    while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  ) {
                                                               ^
dataobj/loadsave.cc:973:56: error: âstruct file_descriptors_tâ has no member named âzoutâ
     size_t ret = ZSTD_decompressStream( fd->dctx, &fd->zout, &fd->zin );
                                                        ^
dataobj/loadsave.cc:973:67: error: âstruct file_descriptors_tâ has no member named âzinâ
     size_t ret = ZSTD_decompressStream( fd->dctx, &fd->zout, &fd->zin );
                                                                   ^
dataobj/loadsave.cc:973:71: error: âZSTD_decompressStreamâ was not declared in this scope
     size_t ret = ZSTD_decompressStream( fd->dctx, &fd->zout, &fd->zin );
                                                                       ^
dataobj/loadsave.cc:975:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.size = fd->zout.pos;
          ^
dataobj/loadsave.cc:975:26: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.size = fd->zout.pos;
                          ^
dataobj/loadsave.cc:979:13: error: âstruct file_descriptors_tâ has no member named âzoutâ
    if(  fd->zout.pos < fd->zout.size  ) {
             ^
dataobj/loadsave.cc:979:28: error: âstruct file_descriptors_tâ has no member named âzoutâ
    if(  fd->zout.pos < fd->zout.size  ) {
                            ^
dataobj/loadsave.cc:980:29: error: âstruct file_descriptors_tâ has no member named âzinâ
     r = fread( (void *)(fd->zin.src), 1, LS_BUF_SIZE, fd->fp );
                             ^
dataobj/loadsave.cc:981:9: error: âstruct file_descriptors_tâ has no member named âzinâ
     fd->zin.pos = 0;
         ^
dataobj/loadsave.cc:982:9: error: âstruct file_descriptors_tâ has no member named âzinâ
     fd->zin.size = r;
         ^
dataobj/loadsave.cc:985:15: error: âstruct file_descriptors_tâ has no member named âzinâ
   while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  );
               ^
dataobj/loadsave.cc:985:29: error: âstruct file_descriptors_tâ has no member named âzinâ
   while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  );
                             ^
dataobj/loadsave.cc:985:47: error: âstruct file_descriptors_tâ has no member named âzoutâ
   while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  );
                                               ^
dataobj/loadsave.cc:985:62: error: âstruct file_descriptors_tâ has no member named âzoutâ
   while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  );
                                                              ^
dataobj/loadsave.cc:986:11: error: âstruct file_descriptors_tâ has no member named âzoutâ
   r = fd->zout.pos; // number of bytes decompressed
           ^

It is not clear why or how these errors do or can occur in circumstances where I have the zstd-dev package installed. Has anyone managed to get ZSTD support working with a GCC/Linux build? If so, what other than libzstd-dev needed to be installed?
Edit: Testing on my local system, Ranran's fix for the file version numbering seems to work - thank you to Ranran for that.

Offline freddyhayward

  • Devotee
  • *
  • Posts: 681
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #248 on: December 03, 2020, 01:25:11 PM »
It looks like just a public player color, not a bug.
I think it's due to a change in the standard related to the theme. At least the same as standard.
Does it still look like this? If so, that is a bug. That does not look like public player at all. And it doesn't matter whether it's related to themes or not.
here are some screenshots:

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20811
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #249 on: December 03, 2020, 01:32:42 PM »
I am not sure that I follow - the new colour for public player station names and town names is the public service player's primary colour (I have tested this, and, if one changes the public service player's primary colour, the text colour changes to match).

In the current master branch and older versions of Standard, this text was white.

Offline freddyhayward

  • Devotee
  • *
  • Posts: 681
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #250 on: December 03, 2020, 01:45:19 PM »
I am not sure that I follow - the new colour for public player station names and town names is the public service player's primary colour (I have tested this, and, if one changes the public service player's primary colour, the text colour changes to match).

In the current master branch and older versions of Standard, this text was white.
The left image shows the bluish text on the merge branch. The public players primary colour is unchanged, as is clearly visible in the station and stop images.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20811
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #251 on: December 03, 2020, 02:41:19 PM »
The left image shows the bluish text on the merge branch. The public players primary colour is unchanged, as is clearly visible in the station and stop images.

The public player's primary colour has indeed not been changed, but the text was formerly not based on the public player's primary colour, but was white. The new code uses the public player colour rather than white. The text in the image is grey rather than blue, which is the public player's default colour.

Offline Ranran

  • Devotee
  • *
  • Posts: 1549
  • Languages: ja
Re: Incorporating changes from Standard
« Reply #252 on: December 03, 2020, 03:39:56 PM »
Regretfully I'm not familiar with Makefile. Therefore, the resolution of the conflict may be omitted.

https://github.com/aburch/simutrans/commit/a83ca95932f44cca97f7d5452c34d8d1a38cc411
The change from line 193 to line 195 in r8910 has been overlooked, is this relevant?
The change in the upper part is irrelevant here as it has been changed again in r8915.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20811
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #253 on: December 03, 2020, 07:14:06 PM »
Regretfully I'm not familiar with Makefile. Therefore, the resolution of the conflict may be omitted.

https://github.com/aburch/simutrans/commit/a83ca95932f44cca97f7d5452c34d8d1a38cc411
The change from line 193 to line 195 in r8910 has been overlooked, is this relevant?
The change in the upper part is irrelevant here as it has been changed again in r8915.

Thank you for that. I have incorporated that and tested it, but, unfortunately, I still get the same errors on a basic native Linux build:

Code: [Select]
===> CXX dataobj/loadsave.cc
dataobj/loadsave.cc:199:2: error: âZSTD_inBufferâ does not name a type
  ZSTD_inBuffer zin;
  ^
dataobj/loadsave.cc:200:2: error: âZSTD_outBufferâ does not name a type
  ZSTD_outBuffer zout;
  ^
dataobj/loadsave.cc: In member function âvoid loadsave_t::set_buffered(bool)â:
dataobj/loadsave.cc:248:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.src = NULL;
          ^
dataobj/loadsave.cc:249:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.size = 0;
          ^
dataobj/loadsave.cc:250:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.pos = 0;
          ^
dataobj/loadsave.cc:252:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.dst = fd->zbuff;
          ^
dataobj/loadsave.cc:253:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.size = LS_BUF_SIZE;
          ^
dataobj/loadsave.cc:254:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.pos = 0;
          ^
dataobj/loadsave.cc:257:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.src = fd->zbuff;
          ^
dataobj/loadsave.cc:258:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.size = LS_BUF_SIZE;
          ^
dataobj/loadsave.cc:259:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.pos = 0;
          ^
dataobj/loadsave.cc:261:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.dst = NULL;
          ^
dataobj/loadsave.cc:262:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.size = 0;
          ^
dataobj/loadsave.cc:263:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.pos = 0;
          ^
dataobj/loadsave.cc: In member function âbool loadsave_t::rd_open(const char*)â:
dataobj/loadsave.cc:370:7: error: âstruct file_descriptors_tâ has no member named âzinâ
   fd->zin.size = 0;
       ^
dataobj/loadsave.cc: In member function âbool loadsave_t::wr_open(const char*, loadsave_t::mode_t, int, const char*, const char*, const char*, const char*)â:
dataobj/loadsave.cc:557:37: error: âZSTD_c_compressionLevelâ was not declared in this scope
   ZSTD_CCtx_setParameter( fd->cctx, ZSTD_c_compressionLevel, level );
                                     ^
dataobj/loadsave.cc:557:68: error: âZSTD_CCtx_setParameterâ was not declared in this scope
   ZSTD_CCtx_setParameter( fd->cctx, ZSTD_c_compressionLevel, level );
                                                                    ^
dataobj/loadsave.cc: In member function âconst char* loadsave_t::close()â:
dataobj/loadsave.cc:672:8: error: âstruct file_descriptors_tâ has no member named âzinâ
    fd->zin.src = "";
        ^
dataobj/loadsave.cc:673:8: error: âstruct file_descriptors_tâ has no member named âzinâ
    fd->zin.size = 0;
        ^
dataobj/loadsave.cc:674:8: error: âstruct file_descriptors_tâ has no member named âzinâ
    fd->zin.pos = 0;
        ^
dataobj/loadsave.cc:676:8: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fd->zout.dst = fd->zbuff;
        ^
dataobj/loadsave.cc:677:8: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fd->zout.size = LS_BUF_SIZE;
        ^
dataobj/loadsave.cc:678:8: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fd->zout.pos = 0;
        ^
dataobj/loadsave.cc:682:9: error: âstruct file_descriptors_tâ has no member named âzoutâ
     fd->zout.pos = 0;
         ^
dataobj/loadsave.cc:683:49: error: âstruct file_descriptors_tâ has no member named âzoutâ
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                 ^
dataobj/loadsave.cc:683:62: error: âstruct file_descriptors_tâ has no member named âzinâ
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                              ^
dataobj/loadsave.cc:683:68: error: âZSTD_e_endâ was not declared in this scope
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                                    ^
dataobj/loadsave.cc:683:80: error: âZSTD_compressStream2â was not declared in this scope
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                                                ^
dataobj/loadsave.cc:684:17: error: âstruct file_descriptors_tâ has no member named âzoutâ
     fwrite( fd->zout.dst, 1, fd->zout.pos, fd->fp );
                 ^
dataobj/loadsave.cc:684:34: error: âstruct file_descriptors_tâ has no member named âzoutâ
     fwrite( fd->zout.dst, 1, fd->zout.pos, fd->fp );
                                  ^
dataobj/loadsave.cc: In member function âvoid loadsave_t::flush_buffer(int)â:
dataobj/loadsave.cc:860:26: error: âstruct file_descriptors_tâ has no member named âzoutâ
   gzwrite( fd->gzfp, fd->zout.dst, fd->zout.pos );
                          ^
dataobj/loadsave.cc:860:40: error: âstruct file_descriptors_tâ has no member named âzoutâ
   gzwrite( fd->gzfp, fd->zout.dst, fd->zout.pos );
                                        ^
dataobj/loadsave.cc:862:7: error: âstruct file_descriptors_tâ has no member named âzinâ
   fd->zin.src = ls_buf[ buf_num ];
       ^
dataobj/loadsave.cc:863:7: error: âstruct file_descriptors_tâ has no member named âzinâ
   fd->zin.size = buf_pos[ buf_num ];
       ^
dataobj/loadsave.cc:864:7: error: âstruct file_descriptors_tâ has no member named âzinâ
   fd->zin.pos = 0;
       ^
dataobj/loadsave.cc:866:15: error: âstruct file_descriptors_tâ has no member named âzinâ
   while(  fd->zin.pos < fd->zin.size  ) {
               ^
dataobj/loadsave.cc:866:29: error: âstruct file_descriptors_tâ has no member named âzinâ
   while(  fd->zin.pos < fd->zin.size  ) {
                             ^
dataobj/loadsave.cc:867:8: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fd->zout.pos = 0;
        ^
dataobj/loadsave.cc:868:48: error: âstruct file_descriptors_tâ has no member named âzoutâ
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
                                                ^
dataobj/loadsave.cc:868:61: error: âstruct file_descriptors_tâ has no member named âzinâ
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
                                                             ^
dataobj/loadsave.cc:868:67: error: âZSTD_e_continueâ was not declared in this scope
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
                                                                   ^
dataobj/loadsave.cc:868:83: error: âZSTD_compressStream2â was not declared in this scope
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
                                                                                   ^
dataobj/loadsave.cc:869:16: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fwrite( fd->zout.dst, 1, fd->zout.pos, fd->fp );
                ^
dataobj/loadsave.cc:869:33: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fwrite( fd->zout.dst, 1, fd->zout.pos, fd->fp );
                                 ^
dataobj/loadsave.cc: In member function âint loadsave_t::fill_buffer(int)â:
dataobj/loadsave.cc:966:7: error: âstruct file_descriptors_tâ has no member named âzoutâ
   fd->zout.dst = ls_buf[ buf_num ];
       ^
dataobj/loadsave.cc:967:7: error: âstruct file_descriptors_tâ has no member named âzoutâ
   fd->zout.size = LS_BUF_SIZE;
       ^
dataobj/loadsave.cc:968:7: error: âstruct file_descriptors_tâ has no member named âzoutâ
   fd->zout.pos = 0;
       ^
dataobj/loadsave.cc:972:16: error: âstruct file_descriptors_tâ has no member named âzinâ
    while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  ) {
                ^
dataobj/loadsave.cc:972:30: error: âstruct file_descriptors_tâ has no member named âzinâ
    while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  ) {
                              ^
dataobj/loadsave.cc:972:48: error: âstruct file_descriptors_tâ has no member named âzoutâ
    while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  ) {
                                                ^
dataobj/loadsave.cc:972:63: error: âstruct file_descriptors_tâ has no member named âzoutâ
    while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  ) {
                                                               ^
dataobj/loadsave.cc:973:56: error: âstruct file_descriptors_tâ has no member named âzoutâ
     size_t ret = ZSTD_decompressStream( fd->dctx, &fd->zout, &fd->zin );
                                                        ^
dataobj/loadsave.cc:973:67: error: âstruct file_descriptors_tâ has no member named âzinâ
     size_t ret = ZSTD_decompressStream( fd->dctx, &fd->zout, &fd->zin );
                                                                   ^
dataobj/loadsave.cc:973:71: error: âZSTD_decompressStreamâ was not declared in this scope
     size_t ret = ZSTD_decompressStream( fd->dctx, &fd->zout, &fd->zin );
                                                                       ^
dataobj/loadsave.cc:975:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.size = fd->zout.pos;
          ^
dataobj/loadsave.cc:975:26: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.size = fd->zout.pos;
                          ^
dataobj/loadsave.cc:979:13: error: âstruct file_descriptors_tâ has no member named âzoutâ
    if(  fd->zout.pos < fd->zout.size  ) {
             ^
dataobj/loadsave.cc:979:28: error: âstruct file_descriptors_tâ has no member named âzoutâ
    if(  fd->zout.pos < fd->zout.size  ) {
                            ^
dataobj/loadsave.cc:980:29: error: âstruct file_descriptors_tâ has no member named âzinâ
     r = fread( (void *)(fd->zin.src), 1, LS_BUF_SIZE, fd->fp );
                             ^
dataobj/loadsave.cc:981:9: error: âstruct file_descriptors_tâ has no member named âzinâ
     fd->zin.pos = 0;
         ^
dataobj/loadsave.cc:982:9: error: âstruct file_descriptors_tâ has no member named âzinâ
     fd->zin.size = r;
         ^
dataobj/loadsave.cc:985:15: error: âstruct file_descriptors_tâ has no member named âzinâ
   while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  );
               ^
dataobj/loadsave.cc:985:29: error: âstruct file_descriptors_tâ has no member named âzinâ
   while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  );
                             ^
dataobj/loadsave.cc:985:47: error: âstruct file_descriptors_tâ has no member named âzoutâ
   while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  );
                                               ^
dataobj/loadsave.cc:985:62: error: âstruct file_descriptors_tâ has no member named âzoutâ
   while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  );
                                                              ^
dataobj/loadsave.cc:986:11: error: âstruct file_descriptors_tâ has no member named âzoutâ
   r = fd->zout.pos; // number of bytes decompressed
           ^
common.mk:55: recipe for target 'build/default/dataobj/loadsave.o' failed
make: *** [build/default/dataobj/loadsave.o] Error 1

Offline TurfIt

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 1434
Re: Incorporating changes from Standard
« Reply #254 on: December 03, 2020, 08:37:07 PM »
ZSTD_inBuffer was added in zstd 0.8.1. You must have older...  Current release is 1.4.5.


EDIT:
Ahhh, now we be cooking.... err threading...
Back to 2700X and bb-17-jan-2020.sve:
  binary, 1T=17434 ms,                                                                    4021 MiB
  zstd 3, 1T=23792 ms, 2T=17934 ms, 4T=18070 ms, 8T=18102 ms, 1150 MiB
  zstd 6, 1T=41689 ms, 2T=24499 ms, 4T=19144 ms, 8T=19333 ms, 1164 MiB
  zstd 9,                                              4T=36967ms, 8T=28007 ms, 1016 MiB,    16T=30320 ms (SMT no go.)

Threading already built into library, just turn it on.
Code: [Select]
ZSTD_CCtx_setParameter( fd->cctx, ZSTD_c_nbWorkers, 16 );

« Last Edit: December 03, 2020, 11:21:58 PM by TurfIt »

Offline freddyhayward

  • Devotee
  • *
  • Posts: 681
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #255 on: December 04, 2020, 03:57:37 AM »
The public player's primary colour has indeed not been changed, but the text was formerly not based on the public player's primary colour, but was white. The new code uses the public player colour rather than white. The text in the image is grey rather than blue, which is the public player's default colour.
This is incorrect because a) it affects all players, not just the public player, b) the original (on right) was clearly also grey, corresponding to the public player's colour, and c) ranran investigated the problem further in this thread: https://forum.simutrans.com/index.php/topic,20560.msg193016/topicseen.html#msg193016

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10681
  • Languages: De,EN,JP
Re: Incorporating changes from Standard
« Reply #256 on: December 04, 2020, 06:18:38 AM »
Test in standard on a four core CPU using a variant of the DOM game using Mingw64 default zstd on a non-debug build.
binary   zstd(6)  zstd(9)  bzip2     zip       zstd(6)1thread  zstd(6)2thread
4665 ms  9174 ms  24464 ms 44263 ms  28389 ms  16919 ms        10796 ms
386MB     101MB   88MB     58MB      102MB

So using a proper buffer and more than one thread I am sold on speed for zstd finally. bUnfourtunately all my server just have single core ...

Offline Ranran

  • Devotee
  • *
  • Posts: 1549
  • Languages: ja
Re: Incorporating changes from Standard
« Reply #257 on: December 04, 2020, 01:50:25 PM »
There was an error merging a commit for Makefile. I've fixed it so please check zstd branch again.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20811
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #258 on: December 05, 2020, 01:07:47 PM »
Ranran - thank you for that.

Thank you also to TurfIt for having spotted the cause of the compile problems set out above: I was indeed using an older version of libzstd. I have now upgraded the Linux distribution on the server, and am running libzstd-dev version 1.3.3.

I am now getting a different compile error, again with a basic native Linux x64 graphical build:

Code: [Select]
expr: syntax error
===> CXX dataobj/loadsave.cc
dataobj/loadsave.cc: In member function âbool loadsave_t::wr_open(const char*, loadsave_t::mode_t, int, const char*, const char*, const char*, const char*)â:
dataobj/loadsave.cc:557:37: error: âZSTD_c_compressionLevelâ was not declared in this scope
   ZSTD_CCtx_setParameter( fd->cctx, ZSTD_c_compressionLevel, level );
                                     ^~~~~~~~~~~~~~~~~~~~~~~
dataobj/loadsave.cc:557:37: note: suggested alternative: âZSTD_decompressStreamâ
   ZSTD_CCtx_setParameter( fd->cctx, ZSTD_c_compressionLevel, level );
                                     ^~~~~~~~~~~~~~~~~~~~~~~
                                     ZSTD_decompressStream
dataobj/loadsave.cc:557:3: error: âZSTD_CCtx_setParameterâ was not declared in this scope
   ZSTD_CCtx_setParameter( fd->cctx, ZSTD_c_compressionLevel, level );
   ^~~~~~~~~~~~~~~~~~~~~~
dataobj/loadsave.cc:557:3: note: suggested alternative: âZSTD_CCtx_sâ
   ZSTD_CCtx_setParameter( fd->cctx, ZSTD_c_compressionLevel, level );
   ^~~~~~~~~~~~~~~~~~~~~~
   ZSTD_CCtx_s
dataobj/loadsave.cc: In member function âconst char* loadsave_t::close()â:
dataobj/loadsave.cc:683:68: error: âZSTD_e_endâ was not declared in this scope
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                                    ^~~~~~~~~~
dataobj/loadsave.cc:683:68: note: suggested alternative: âZSTD_DDictâ
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                                    ^~~~~~~~~~
                                                                    ZSTD_DDict
dataobj/loadsave.cc:683:11: error: âZSTD_compressStream2â was not declared in this scope
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
           ^~~~~~~~~~~~~~~~~~~~
dataobj/loadsave.cc:683:11: note: suggested alternative: âZSTD_compressStreamâ
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
           ^~~~~~~~~~~~~~~~~~~~
           ZSTD_compressStream
dataobj/loadsave.cc: In member function âvoid loadsave_t::flush_buffer(int)â:
dataobj/loadsave.cc:868:67: error: âZSTD_e_continueâ was not declared in this scope
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
                                                                   ^~~~~~~~~~~~~~~
dataobj/loadsave.cc:868:10: error: âZSTD_compressStream2â was not declared in this scope
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
          ^~~~~~~~~~~~~~~~~~~~
dataobj/loadsave.cc:868:10: note: suggested alternative: âZSTD_compressStreamâ
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
          ^~~~~~~~~~~~~~~~~~~~
          ZSTD_compressStream
dataobj/loadsave.cc: In member function âint loadsave_t::fill_buffer(int)â:
dataobj/loadsave.cc:980:36: warning: cast from type âconst void*â to type âvoid*â casts away qualifiers [-Wcast-qual]
     r = fread( (void *)(fd->zin.src), 1, LS_BUF_SIZE, fd->fp );
                                    ^
common.mk:55: recipe for target 'build/default/dataobj/loadsave.o' failed
make: *** [build/default/dataobj/loadsave.o] Error 1

This appears to be trying to use Zstd calls or parameters not supported. I am not sure whether even version 1.3.3 is too old for the code, or whether there is some other sort of error. Any enlightenment would be appreciated.

Offline TurfIt

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 1434
Re: Incorporating changes from Standard
« Reply #259 on: December 05, 2020, 07:31:19 PM »
Too old. You've 'upgraded' all the way to a 2017 version of zstd. Come a little further to 2018 with 1.3.8, and you might get it to work (these functions are still in the experimental section at that time - need manual enablement). 1.4.0 is when the API is declared stable, so likely works there. But really, if use of the library was added in 2020, why not use a version of the library from 2020....   As said before, 1.4.5 is the current release, and is what I tested with.

Offline Andarix

  • *
  • Posts: 277
  • Languages: de
Re: Incorporating changes from Standard
« Reply #260 on: December 05, 2020, 07:36:50 PM »
zstd 1.4.4 works by me on GitHub

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20811
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #261 on: December 05, 2020, 07:47:53 PM »
I have been using the package that comes with the Ubuntu distribution that the server uses. I have recently upgraded that from 16.04 to 18.04 (do-release-upgrade does not appear to take it all the way to 20.04). I will need either manually to install a later package or upgrade the server distribution again.

Thank you for this, however: it is most helpful to know what the problem is.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20811
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #262 on: December 06, 2020, 05:03:42 PM »
I have now managed to upgrade to 20.04, which includes version 1.4.4 of libzstd-dev. This has fixed the libzstd compile errors. However, I am now encountering freetype related linker errors:

Code: [Select]
===> LD  build/default/simutrans-extended
/usr/bin/ld: build/default/gui/loadfont_frame.o: in function `loadfont_frame_t::check_file(char const*, char const*)':
loadfont_frame.cc:(.text+0x22e): undefined reference to `FT_New_Face'
/usr/bin/ld: loadfont_frame.cc:(.text+0x241): undefined reference to `FT_Get_Char_Index'
/usr/bin/ld: loadfont_frame.cc:(.text+0x29c): undefined reference to `FT_Done_Face'
/usr/bin/ld: loadfont_frame.cc:(.text+0x30a): undefined reference to `FT_Get_Char_Index'
/usr/bin/ld: build/default/gui/loadfont_frame.o: in function `loadfont_frame_t::fill_list()':
loadfont_frame.cc:(.text+0x633): undefined reference to `FT_Init_FreeType'
/usr/bin/ld: loadfont_frame.cc:(.text+0x6af): undefined reference to `FT_New_Face'
/usr/bin/ld: loadfont_frame.cc:(.text+0x706): undefined reference to `FT_Done_Face'
/usr/bin/ld: loadfont_frame.cc:(.text+0x724): undefined reference to `FT_Done_FreeType'
/usr/bin/ld: build/default/display/font.o: in function `font_t::load_from_freetype(char const*, int)':
font.cc:(.text+0xeca): undefined reference to `FT_Init_FreeType'
/usr/bin/ld: font.cc:(.text+0xee6): undefined reference to `FT_New_Face'
/usr/bin/ld: font.cc:(.text+0xefd): undefined reference to `FT_Set_Pixel_Sizes'
/usr/bin/ld: font.cc:(.text+0x1017): undefined reference to `FT_Get_Char_Index'
/usr/bin/ld: font.cc:(.text+0x1030): undefined reference to `FT_Load_Glyph'
/usr/bin/ld: font.cc:(.text+0x104a): undefined reference to `FT_Render_Glyph'
/usr/bin/ld: font.cc:(.text+0x10ac): undefined reference to `FT_Done_FreeType'
/usr/bin/ld: font.cc:(.text+0x1305): undefined reference to `FT_Done_Face'
/usr/bin/ld: font.cc:(.text+0x130f): undefined reference to `FT_Done_FreeType'
/usr/bin/ld: font.cc:(.text+0x135e): undefined reference to `FT_Done_Face'
/usr/bin/ld: font.cc:(.text+0x1368): undefined reference to `FT_Done_FreeType'
collect2: error: ld returned 1 exit status
make: *** [common.mk:27: build/default/simutrans-extended] Error 1


This looks like I am missing a library reference somewhere, as I have installed the freetype2 dev package. I cannot find any freetype folders in /usr/lib, and I am not sure where I should be looking for these. Any assistance would be appreciated.

Offline R1dO

  • *
  • Posts: 43
  • Languages: NL EN
Re: Incorporating changes from Standard
« Reply #263 on: December 06, 2020, 08:00:45 PM »
Even though i have now idea how your compiling workflow is you might benefit from the discussion over here: https://forum.simutrans.com/index.php/topic,19011.msg180232.html#msg180232

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20811
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #264 on: December 08, 2020, 08:36:35 PM »
I have now managed to get the basic graphical client in Linux to compile, after finding that I needed manually to specify the library files for Freetype.

However, I am now having a separate compile problem with the server build:

Code: [Select]
===> CXX utils/log.cc
utils/log.cc: In member function ‘void log_t::doubled(const char*, const char*)’:
utils/log.cc:238:75: error: expression cannot be used as a function
  238 |    syslog( LOG_WARNING, "Warning: object %s::%s is overlaid!", what, name );
      |                                                                           ^
utils/log.cc: In member function ‘void log_t::fatal(const char*, const char*, ...)’:
utils/log.cc:274:22: warning: format not a string literal and no format arguments [-Wformat-security]
  274 |   ::syslog( LOG_ERR, buffer );
      |                      ^~~~~~
utils/log.cc: In constructor ‘log_t::log_t(const char*, bool, bool, bool, const char*, const char*)’:
utils/log.cc:419:35: warning: format not a string literal and no format arguments [-Wformat-security]
  419 |    ::syslog( LOG_NOTICE, greeting );
      |                                   ^
make: *** [common.mk:56: build/server/utils/log.o] Error 1

This appears to be an error with the logging function; I know very little about the logging code. May I ask whether Ranran knows what has changed here so that we can begin the process of tracking down the cause of this problem?

The cross-compile builds are the thing to deal with after this; they will need a vast amount of work, as I will need to download and build cross-compile libraries for freetype2, miniupnpc and zstd. I recall that producing cross-compile libraries was a long and difficult struggle on the last occasion that I attempted it.

Offline Ranran

  • Devotee
  • *
  • Posts: 1549
  • Languages: ja
Re: Incorporating changes from Standard
« Reply #265 on: December 08, 2020, 10:02:18 PM »
This appears to be an error with the logging function; I know very little about the logging code. May I ask whether Ranran knows what has changed here so that we can begin the process of tracking down the cause of this problem?
I think it was because r8584 wasn't merged.
I would appreciate it if you could try it again.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20811
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #266 on: December 08, 2020, 10:51:19 PM »
I think it was because r8584 wasn't merged.
I would appreciate it if you could try it again.

That works - excellent, thank you for the fix.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20811
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #267 on: December 09, 2020, 01:50:53 AM »
I have made some significant progress with this this evening - I have managed to get a 64-bit Windows build running on the merge-from-standard-zstd branch and working without the crash reported in to-day's nightly builds (I will post more on that in the other thread shortly).

There is one problem at present, however, which is that I cannot get the miniupnpc integration working. The problem is that I have been unable to compile a statically linked cross-compile library for miniupnpc; attempting to do so will give rise to the linker errors associated with attempting to link to a dynamic library instead of a static library. I spent some time trying to solve this without success. I am not sure how important that miniupnpc is, as the game will compile satisfactorily without this feature and the current master branch also does not have this feature.

I should be grateful for feedback on this question, and, if it is an important enough issue to solve, some assistance in solving it.

The next step will be testing the new build. The version that I have compiled this evening can be found here. Any intrepid testers are encouraged to report findings on this thread so that Ranran and/or I (as appropriate) can look into and address the issues found.

As many people as possible testing the zstd compression speed as against the zlib compression speed would also be very helpful.

Thank you to all those who have worked on this so far, especially Ranran - it is much appreciated.

Offline Ranran

  • Devotee
  • *
  • Posts: 1549
  • Languages: ja
Re: Incorporating changes from Standard
« Reply #268 on: December 09, 2020, 02:00:49 AM »
The next step will be testing the new build. The version that I have compiled this evening can be found here. Any intrepid testers are encouraged to report findings on this thread so that Ranran and/or I (as appropriate) can look into and address the issues found.
It seems that the selectable fonts in my self-build version cannot be changed in this build.
Fonts in the windows folder are not selectable in this build. (under c:\Windows\Fonts\ )

It seems that the commit number is standard's one (#9495). Did I overwrite the settings by merging standard commits?

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20811
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #269 on: December 09, 2020, 11:15:42 AM »
It seems that the selectable fonts in my self-build version cannot be changed in this build.
Fonts in the windows folder are not selectable in this build. (under c:\Windows\Fonts\ )

It seems that the commit number is standard's one (#9495). Did I overwrite the settings by merging standard commits?

I note that I was compiling with FREETYPE = 0 in the makefile configuration. I suspect that this is because I had difficulty setting up libraries for this when I first started cross compiling some time ago. I will look into whether I can enable this, but I am not sure whether I shall be able to do so.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20811
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #270 on: December 09, 2020, 12:09:24 PM »
I have looked into this and am having intractible problems in compiling a cross-compile compatible version of freetype2.

For some reason, when I amend the configuration files to point to the correct cross-compiler, the cross-compiler seems to fail to recognise the forward slashes used to denote directories and reports:

Code: [Select]
x86_64-w64-mingw32-gcc  -I.\objs -I.\builds\windows -I.\include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs\ftsystem.obj src\base\ftsystem.c
x86_64-w64-mingw32-gcc: error: srcbaseftsystem.c: No such file or directory
x86_64-w64-mingw32-gcc: fatal error: no input files
compilation terminated.
make: *** [builds/freetype.mk:204: objs/ftsystem.obj] Error 1

This really makes no sense at all; any assistance in resolving this would be appreciated.

Offline TurfIt

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 1434
Re: Incorporating changes from Standard
« Reply #271 on: December 09, 2020, 12:49:43 PM »
src/base/ftsystem.c    'src\base\ftsystem.c'    src\\base\\ftsystem.c

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20811
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #272 on: December 09, 2020, 02:09:06 PM »
src/base/ftsystem.c    'src\base\ftsystem.c'    src\\base\\ftsystem.c


Thank you for that. The configuration files for Freetype are very difficult to deal with (and extremely numerous) and, so far as I can tell, very poorly documented. There was a backslash specified in one of them, which, when changed to a forward slash, eliminated the error. However, I now get another error:

Code: [Select]
x86_64-w64-mingw32-gcc  -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftsystem.obj src/base/ftsystem.c
x86_64-w64-mingw32-gcc  -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftdebug.obj src/base/ftdebug.c
x86_64-w64-mingw32-gcc  -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftinit.obj src/base/ftinit.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftbase.obj ./src/base/ftbase.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftbbox.obj src/base/ftbbox.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftbdf.obj src/base/ftbdf.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftbitmap.obj src/base/ftbitmap.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftcid.obj src/base/ftcid.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftfstype.obj src/base/ftfstype.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftgasp.obj src/base/ftgasp.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftglyph.obj src/base/ftglyph.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftgxval.obj src/base/ftgxval.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftmm.obj src/base/ftmm.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftotval.obj src/base/ftotval.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftpatent.obj src/base/ftpatent.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftpfr.obj src/base/ftpfr.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftstroke.obj src/base/ftstroke.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftsynth.obj src/base/ftsynth.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/fttype1.obj src/base/fttype1.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftwinfnt.obj src/base/ftwinfnt.c
x86_64-w64-mingw32-gcc  -I./src/truetype -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/truetype.obj ./src/truetype/truetype.c
x86_64-w64-mingw32-gcc  -I./src/type1 -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/type1.obj ./src/type1/type1.c
x86_64-w64-mingw32-gcc  -I./src/cff -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/cff.obj ./src/cff/cff.c
x86_64-w64-mingw32-gcc  -I./src/cid -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/type1cid.obj ./src/cid/type1cid.c
x86_64-w64-mingw32-gcc  -I./src/pfr -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/pfr.obj ./src/pfr/pfr.c
x86_64-w64-mingw32-gcc  -I./src/type42 -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/type42.obj ./src/type42/type42.c
x86_64-w64-mingw32-gcc  -I./src/winfonts -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/winfnt.obj ./src/winfonts/winfnt.c
x86_64-w64-mingw32-gcc  -I./src/pcf -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/pcf.obj ./src/pcf/pcf.c
x86_64-w64-mingw32-gcc  -I./src/bdf -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/bdf.obj ./src/bdf/bdf.c
x86_64-w64-mingw32-gcc  -I./src/sfnt -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/sfnt.obj ./src/sfnt/sfnt.c
x86_64-w64-mingw32-gcc  -I./src/autofit -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/autofit.obj ./src/autofit/autofit.c
x86_64-w64-mingw32-gcc  -I./src/pshinter -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/pshinter.obj ./src/pshinter/pshinter.c
x86_64-w64-mingw32-gcc  -I./src/raster -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/raster.obj ./src/raster/raster.c
x86_64-w64-mingw32-gcc  -I./src/smooth -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/smooth.obj ./src/smooth/smooth.c
x86_64-w64-mingw32-gcc  -I./src/cache -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftcache.obj ./src/cache/ftcache.c
x86_64-w64-mingw32-gcc  -I./src/gzip -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftgzip.obj ./src/gzip/ftgzip.c
x86_64-w64-mingw32-gcc  -I./src/lzw -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftlzw.obj ./src/lzw/ftlzw.c
x86_64-w64-mingw32-gcc  -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftbzip2.obj ./src/bzip2/ftbzip2.c
x86_64-w64-mingw32-gcc  -I./src/psaux -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/psaux.obj ./src/psaux/psaux.c
x86_64-w64-mingw32-gcc  -I./src/psnames -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/psnames.obj ./src/psnames/psnames.c
lcclib /out:objs/freetype.lib  ./objs/ftsystem.obj ./objs/ftdebug.obj ./objs/ftinit.obj ./objs/ftbase.obj ./objs/ftbbox.obj ./objs/ftbdf.obj ./objs/ftbitmap.obj ./objs/ftcid.obj ./objs/ftfstype.obj ./objs/ftgasp.obj ./objs/ftglyph.obj ./objs/ftgxval.obj ./objs/ftmm.obj ./objs/ftotval.obj ./objs/ftpatent.obj ./objs/ftpfr.obj ./objs/ftstroke.obj ./objs/ftsynth.obj ./objs/fttype1.obj ./objs/ftwinfnt.obj ./objs/truetype.obj ./objs/type1.obj ./objs/cff.obj ./objs/type1cid.obj ./objs/pfr.obj ./objs/type42.obj ./objs/winfnt.obj ./objs/pcf.obj ./objs/bdf.obj ./objs/sfnt.obj ./objs/autofit.obj ./objs/pshinter.obj ./objs/raster.obj ./objs/smooth.obj ./objs/ftcache.obj ./objs/ftgzip.obj ./objs/ftlzw.obj ./objs/ftbzip2.obj ./objs/psaux.obj ./objs/psnames.obj ./objs/truetype.obj ./objs/type1.obj ./objs/cff.obj ./objs/type1cid.obj ./objs/pfr.obj ./objs/type42.obj ./objs/winfnt.obj ./objs/pcf.obj ./objs/bdf.obj ./objs/sfnt.obj ./objs/autofit.obj ./objs/pshinter.obj ./objs/raster.obj ./objs/smooth.obj ./objs/ftcache.obj ./objs/ftgzip.obj ./objs/ftlzw.obj ./objs/ftbzip2.obj ./objs/psaux.obj ./objs/psnames.obj
make: lcclib: Command not found
make: *** [config.mk:55: objs/freetype.lib] Error 127

The reference to a .lib file, combined with the earlier specification of the backslash, makes me wonder whether the configuration that I am using for Freetype is not a configuration for producing libraries for a cross-compile build, but rather a configuration for cross-compiling libraries for use when compiling using those libraries on Windows machines. If that is so, then it is very unclear to me how to configure the various configuration files to build libraries for cross compiling.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10681
  • Languages: De,EN,JP
Re: Incorporating changes from Standard
« Reply #273 on: December 09, 2020, 02:09:46 PM »
Since even windows can hande "/" as path seperator, I strongly suggest to forget using "\" at all. Just use "/" is all pathes.

For crosscompiling, I found most useful to have a file in my oath, called mingw64
Code: [Select]
#!/bin/sh
PREFIX=i686-w64-mingw32
export CC=$PREFIX-gcc
export CXX=$PREFIX-g++
export CPP=$PREFIX-cpp
export WINDRES=$PREFIX-windres
export AR=$PREFIX-ar
export RANLIB=$PREFIX-ranlib
export PATH="/usr/i686-w64-mingw32/bin:$PATH"
exec "$@"

Then the actual crosscompiling script looks like this:
Code: [Select]
cd /home/simutrans/mingw64/trunk
rm simu*.zip
rm sim
rm sim.exe
rm config.default
cp config.default.gdi config.default
export export PATH="/home/simutrans/bin:$PATH"
svn revert -R .
svn up
mingw64 gcc -xc++ -dM -E - < /dev/null
mingw64 make clean
mingw64 make
mingw64 strip sim
mv sim sim.exe
/home/simutrans/mingw64/trunk/distribute.sh
rm sim.exe
svn revert -R .
mingw64 make clean
rm -rf /home/simutrans/mingw64/trunk/build

If you copy the *.h files and the .a into the respective include and lib fodlers, then the crosscompiler finds libfreetype and compiles it without any extra pathes. Also for compiling freetype, forget about the stupid libharfbuzz. That adds 3 MB for nothing Simutrans can use. Without it (and maybe even without libbrotli) freetypes compiles easily.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20811
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #274 on: December 09, 2020, 02:12:49 PM »
Prissi - thank you for that. The problem that I am having at present is the cross-compiling of the cross-compile Freetype libraries; aside from missing Freetype libraries, I can cross-compile a working build of Simutrans-Extended (albeit only one with Freetype disabled).

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10681
  • Languages: De,EN,JP
Re: Incorporating changes from Standard
« Reply #275 on: December 09, 2020, 02:15:24 PM »
Sorry, see my edit. Freetype can do with libharfbuzz.

if you have a mingw64 script like my example, then you can use the "mingw64 ./configure  --without-harfbuzz ..." to build the lib. Or just compile the lib under windows and upload it to your server ...

Offline TurfIt

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 1434
Re: Incorporating changes from Standard
« Reply #276 on: December 09, 2020, 03:10:33 PM »
If that is so, then it is very unclear to me how to configure the various configuration files to build libraries for cross compiling.
Is there something wrong with './configure --build={whatever your build system is} --host=x86_64-w64-mingw32'  as specified in freetype-2.10.4/docs/INSTALL.CROSS?  (and of course with --prefix as needed...)

Offline Matthew

  • Devotee
  • *
  • Posts: 580
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
Re: Incorporating changes from Standard
« Reply #277 on: December 09, 2020, 05:13:24 PM »
I just want to point out a decision which seem to be being made by default in this thread.

The existing cross-compilation process is not documented at all. This is for a very good reason. James, you are self-taught coder who just wants something that works, since you are primarily interested in transport and Simutrans, not wading through obscure details of harfbuzz. That is entirely understandable - that's where I'm coming from too. But the short-term fix is not ideal in the long-run because (a) if you are the only person who can cross-compile Extended, it increases the demands on you and (b) it means the Extended build process becomes dependent upon where files are located in one particular system (Bridgewater-Brunel).

The CMake build process was intended to get Extended out of this hole by moving to a single build process that works everywhere and manages dependencies wherever possible. It also integrates with Github Actions, which also reduces the project's dependency on Bridgewater-Brunel.

The way that the very real dependency problems are being tackled in this thread is digging us further into the hole of undocumented, B-B-dependent compilation. I understand that it's easier in the short-term. And I guess it would be possible to use the old system first and move to CMake later, at the cost of doing all the work twice. But the fact that B-B has just been updated and you and Ranran are very kindly integrating a large number of Standard features in one go means this may well be the best opportunity for several years to move dependency management over to the CMake-based process.

I can't offer to help you to move to a CMake process, because I know much less than anyone else here about coding. I can't even promise it will be easier. But I would urge you to step back for a moment to consider whether you really want to stay with the existing process or move to a CMake-based process, since that decision is being made by default.

I have made some significant progress with this this evening - I have managed to get a 64-bit Windows build running on the merge-from-standard-zstd branch and working without the crash reported in to-day's nightly builds (I will post more on that in the other thread shortly).

...
The next step will be testing the new build. The version that I have compiled this evening can be found here. Any intrepid testers are encouraged to report findings on this thread so that Ranran and/or I (as appropriate) can look into and address the issues found.

I can confirm that it runs on my Windows 10 VM with an offline B-B save from today and that the follow-me-underground feature is really cool!  8)

I am aware that it would be helpful to test out the theming features. Anything else?

Quote
As many people as possible testing the zstd compression speed as against the zlib compression speed would also be very helpful.

Hmm. I need to sit down and work out how to do this.

Quote
Thank you to all those who have worked on this so far, especially Ranran - it is much appreciated.

Ranran, I can see from Github that your have poured dozens if not hundreds of hours into this project. Thank you so much!

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20811
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #278 on: December 09, 2020, 05:20:11 PM »
Thank you all for your help. Unfortunately, I have still not succeeded in building a workable freetype library. Using TurfIt's suggestion, the build of the library apparently completes without errors, but attempting to compile Simutrans-Extended results in:

Code: [Select]
===> LD  build/mingw64/Simutrans-Extended.exe
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0xf18): undefined reference to `FT_Init_FreeType'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0xf35): undefined reference to `FT_New_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0xf4c): undefined reference to `FT_Set_Pixel_Sizes'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1060): undefined reference to `FT_Get_Char_Index'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x107d): undefined reference to `FT_Load_Glyph'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1094): undefined reference to `FT_Render_Glyph'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1149): undefined reference to `FT_Done_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1153): undefined reference to `FT_Done_FreeType'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1184): undefined reference to `FT_Done_FreeType'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1357): undefined reference to `FT_Done_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1361): undefined reference to `FT_Done_FreeType'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x20b): undefined reference to `FT_New_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x21e): undefined reference to `FT_Get_Char_Index'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x22c): undefined reference to `FT_Done_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x2d3): undefined reference to `FT_Get_Char_Index'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x635): undefined reference to `FT_Init_FreeType'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x6b1): undefined reference to `FT_New_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x708): undefined reference to `FT_Done_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x725): undefined reference to `FT_Done_FreeType'
collect2: error: ld returned 1 exit status
make: *** [common.mk:27: build/mingw64/Simutrans-Extended.exe] Error 1

I execute this command:

Code: [Select]
./configure --host=x86_64-w64-mingw32 --without-harfbuzz

and get this apparently correct output:

Code: [Select]
FreeType build system -- automatic system detection

The following settings are used:

  platform                    unix
  compiler                    cc
  configuration directory     ./builds/unix
  configuration rules         ./builds/unix/unix.mk

If this does not correspond to your system or settings please remove the file
`config.mk' from this directory then read the INSTALL file for help.

Otherwise, simply type `make' again to build the library,
or `make refdoc' to build the API reference (this needs Python >= 3.5).

cd builds/unix; \
        ./configure  '--host=x86_64-w64-mingw32' '--without-harfbuzz'
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-w64-mingw32
checking for x86_64-w64-mingw32-gcc... x86_64-w64-mingw32-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-w64-mingw32-gcc accepts -g... yes
checking for x86_64-w64-mingw32-gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... x86_64-w64-mingw32-gcc -E
checking for x86_64-w64-mingw32-pkg-config... /usr/bin/x86_64-w64-mingw32-pkg-config
checking pkg-config is at least version 0.24... Please install dpkg-dev to use pkg-config when cross-building
no
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by x86_64-w64-mingw32-gcc... /usr/bin/x86_64-w64-mingw32-ld
checking if the linker (/usr/bin/x86_64-w64-mingw32-ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/x86_64-w64-mingw32-nm -B
checking the name lister (/usr/bin/x86_64-w64-mingw32-nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-w64-mingw32 format... func_convert_file_nix_to_w32
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/x86_64-w64-mingw32-ld option to reload object files... -r
checking for x86_64-w64-mingw32-objdump... x86_64-w64-mingw32-objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for x86_64-w64-mingw32-dlltool... x86_64-w64-mingw32-dlltool
checking how to associate runtime and link libraries... func_cygming_dll_for_implib
checking for x86_64-w64-mingw32-ar... x86_64-w64-mingw32-ar
checking for archiver @FILE support... @
checking for x86_64-w64-mingw32-strip... x86_64-w64-mingw32-strip
checking for x86_64-w64-mingw32-ranlib... x86_64-w64-mingw32-ranlib
checking for gawk... no
checking for mawk... mawk
checking command to parse /usr/bin/x86_64-w64-mingw32-nm -B output from x86_64-w64-mingw32-gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for x86_64-w64-mingw32-mt... no
checking for mt... mt
configure: WARNING: using cross tools not prefixed with host triplet
checking if mt is a manifest tool... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... no
checking for x86_64-w64-mingw32-as... x86_64-w64-mingw32-as
checking for x86_64-w64-mingw32-dlltool... (cached) x86_64-w64-mingw32-dlltool
checking for x86_64-w64-mingw32-objdump... (cached) x86_64-w64-mingw32-objdump
checking for objdir... .libs
checking if x86_64-w64-mingw32-gcc supports -fno-rtti -fno-exceptions... no
checking for x86_64-w64-mingw32-gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if x86_64-w64-mingw32-gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if x86_64-w64-mingw32-gcc static flag -static works... yes
checking if x86_64-w64-mingw32-gcc supports -c -o file.o... yes
checking if x86_64-w64-mingw32-gcc supports -c -o file.o... (cached) yes
checking whether the x86_64-w64-mingw32-gcc linker (/usr/bin/x86_64-w64-mingw32-ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking windows.h usability... yes
checking windows.h presence... yes
checking for windows.h... yes
checking for x86_64-w64-mingw32-windres... x86_64-w64-mingw32-windres
checking for x86_64-pc-linux-gnu-gcc... no
checking for gcc... gcc
checking for gcc... (cached) gcc
checking for suffix of native executables...
checking for a BSD-compatible install... /usr/bin/install -c
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for ANSI C header files... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking for unistd.h... (cached) yes
checking for an ANSI C-conforming const... yes
checking size of int... 4
checking size of long... 4
checking for unsigned long long int... yes
checking for long long int... yes
checking whether cpp computation of bit length in ftconfig.h.in works... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/param.h... yes
checking for getpagesize... yes
checking for working mmap... no
checking for memcpy... yes
checking for memmove... yes
checking for -fvisibility=hidden compiler flag... yes
checking for ZLIB... no
checking for gzsetparams in -lz... no
checking for BZIP2... no
checking for BZ2_bzDecompress in -lbz2... no
checking for LIBPNG... no
checking for libpng-config... yes
checking for BROTLI... no
checking for library containing clock_gettime... no
checking for python3... python3
checking for python version... 3.8.5
checking for `docwriter' Python module... no
configure: creating ./config.status
config.status: creating ftoption.h
config.status: creating unix-cc.mk
config.status: creating unix-def.mk
config.status: creating ftconfig.h
config.status: ftconfig.h is unchanged
config.status: executing libtool commands
configure:

Library configuration:
  external zlib: no
  bzip2:         no
  libpng:        yes (libpng-config)
  harfbuzz:      no
  brotli:        no

configure: WARNING:
  `make refdoc' will fail since pip package `docwriter' is not installed.
  To install, run `python3 -m pip install docwriter', or to use a Python
  virtual environment, run `make refdoc-venv' (requires pip package
  `virtualenv'). These operations require Python >= 3.5.

I then issue a "make" command and get an output too long to reproduce here, but which appears to conclude without error, albeit there are some warnings at the end:

Code: [Select]
*** Warning: linker path does not have real file for library -lz.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libz but no candidates were found. (...for file magic test)

*** Warning: linker path does not have real file for library -lm.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libm and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/x86_64-w64-mingw32/lib/libm.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
libtool: link: x86_64-w64-mingw32-ar cru /root/freetype-2.10.4/objs/.libs/libfreetype.a  /root/freetype-2.10.4/objs/ftsystem.o /root/freetype-2.10.4/objs/ftdebug.o /root/freetype-2.10.4/objs/ftinit.o /root/freetype-2.10.4/objs/ftver.o /root/freetype-2.10.4/objs/ftbase.o /root/freetype-2.10.4/objs/ftbbox.o /root/freetype-2.10.4/objs/ftbdf.o /root/freetype-2.10.4/objs/ftbitmap.o /root/freetype-2.10.4/objs/ftcid.o /root/freetype-2.10.4/objs/ftfstype.o /root/freetype-2.10.4/objs/ftgasp.o /root/freetype-2.10.4/objs/ftglyph.o /root/freetype-2.10.4/objs/ftgxval.o /root/freetype-2.10.4/objs/ftmm.o /root/freetype-2.10.4/objs/ftotval.o /root/freetype-2.10.4/objs/ftpatent.o /root/freetype-2.10.4/objs/ftpfr.o /root/freetype-2.10.4/objs/ftstroke.o /root/freetype-2.10.4/objs/ftsynth.o /root/freetype-2.10.4/objs/fttype1.o /root/freetype-2.10.4/objs/ftwinfnt.o /root/freetype-2.10.4/objs/truetype.o /root/freetype-2.10.4/objs/type1.o /root/freetype-2.10.4/objs/cff.o /root/freetype-2.10.4/objs/type1cid.o /root/freetype-2.10.4/objs/pfr.o /root/freetype-2.10.4/objs/type42.o /root/freetype-2.10.4/objs/winfnt.o /root/freetype-2.10.4/objs/pcf.o /root/freetype-2.10.4/objs/bdf.o /root/freetype-2.10.4/objs/sfnt.o /root/freetype-2.10.4/objs/autofit.o /root/freetype-2.10.4/objs/pshinter.o /root/freetype-2.10.4/objs/raster.o /root/freetype-2.10.4/objs/smooth.o /root/freetype-2.10.4/objs/ftcache.o /root/freetype-2.10.4/objs/ftgzip.o /root/freetype-2.10.4/objs/ftlzw.o /root/freetype-2.10.4/objs/ftbzip2.o /root/freetype-2.10.4/objs/psaux.o /root/freetype-2.10.4/objs/psnames.o
x86_64-w64-mingw32-ar: `u' modifier ignored since `D' is the default (see `U')
libtool: link: x86_64-w64-mingw32-ranlib /root/freetype-2.10.4/objs/.libs/libfreetype.a
libtool: link: ( cd "/root/freetype-2.10.4/objs/.libs" && rm -f "libfreetype.la" && ln -s "../libfreetype.la" "libfreetype.la" )

Having done that, issuing a make command for Simutrans-Extended with the mingw64 compile option gives the errors set out above. For reference, the following is set in config.mingw64:

Code: [Select]
LDFLAGS = -L/root/freetype-2.10.4

/root/freetype-2.10.4 is the directory in which I have extracted and built the Freetype libraries. I have also tried

Code: [Select]
LDFLAGS = -L/root/freetype-2.10.4/objs

also without success. I am not sure quite what further thing that I can try, especially as the build appears to complete without errors but I am unable to link from Simutrans-Extended.
For reference, these are the contents of the relevant folders:
Code: [Select]
root@438242:~/freetype-2.10.4/objs# ls -l
total 5492
-rwxr-xr-x 1 root          root   22112 Dec  9 16:39 apinames
-rw-r--r-- 1 root          root     300 Dec  9 17:11 autofit.lo
-rw-r--r-- 1 root          root  405887 Dec  9 17:11 autofit.o
-rw-r--r-- 1 root          root     288 Dec  9 17:10 bdf.lo
-rw-r--r-- 1 root          root  132609 Dec  9 17:10 bdf.o
-rw-r--r-- 1 root          root     288 Dec  9 17:10 cff.lo
-rw-r--r-- 1 root          root  294089 Dec  9 17:10 cff.o
-rw-r--r-- 1 root          root     297 Dec  9 17:09 ftbase.lo
-rw-r--r-- 1 root          root  643683 Dec  9 17:09 ftbase.o
-rw-r--r-- 1 root          root     297 Dec  9 17:10 ftbbox.lo
-rw-r--r-- 1 root          root   18364 Dec  9 17:10 ftbbox.o
-rw-r--r-- 1 root          root     294 Dec  9 17:10 ftbdf.lo
-rw-r--r-- 1 root          root   22426 Dec  9 17:10 ftbdf.o
-rw-r--r-- 1 root          root     303 Dec  9 17:10 ftbitmap.lo
-rw-r--r-- 1 root          root   60821 Dec  9 17:10 ftbitmap.o
-rw-r--r-- 1 root          root     300 Dec  9 17:11 ftbzip2.lo
-rw-r--r-- 1 root          root    8181 Dec  9 17:11 ftbzip2.o
-rw-r--r-- 1 root          root     300 Dec  9 17:11 ftcache.lo
-rw-r--r-- 1 root          root  168990 Dec  9 17:11 ftcache.o
-rw-r--r-- 1 root          root     294 Dec  9 17:10 ftcid.lo
-rw-r--r-- 1 root          root   23517 Dec  9 17:10 ftcid.o
-rw-r--r-- 1 root          root     300 Dec  9 17:09 ftdebug.lo
-rw-r--r-- 1 root          root    3561 Dec  9 17:09 ftdebug.o
-rw-r--r-- 1 root          root    3978 Dec  9 16:39 ftexport.sym
-rw-r--r-- 1 root          root     303 Dec  9 17:10 ftfstype.lo
-rw-r--r-- 1 root          root   21184 Dec  9 17:10 ftfstype.o
-rw-r--r-- 1 root          root     297 Dec  9 17:10 ftgasp.lo
-rw-r--r-- 1 root          root   26252 Dec  9 17:10 ftgasp.o
-rw-r--r-- 1 root          root     300 Dec  9 17:10 ftglyph.lo
-rw-r--r-- 1 root          root   44615 Dec  9 17:10 ftglyph.o
-rw-r--r-- 1 root          root     300 Dec  9 17:10 ftgxval.lo
-rw-r--r-- 1 root          root   24132 Dec  9 17:10 ftgxval.o
-rw-r--r-- 1 root          root     297 Dec  9 17:11 ftgzip.lo
-rw-r--r-- 1 root          root  134120 Dec  9 17:11 ftgzip.o
-rw-r--r-- 1 root          root     297 Dec  9 17:09 ftinit.lo
-rw-r--r-- 1 root          root   26131 Dec  9 17:09 ftinit.o
-rw-r--r-- 1 root          root     294 Dec  9 17:11 ftlzw.lo
-rw-r--r-- 1 root          root   35788 Dec  9 17:11 ftlzw.o
-rw-r--r-- 1 root          root     291 Dec  9 17:10 ftmm.lo
-rw-r--r-- 1 root          root   46102 Dec  9 17:10 ftmm.o
-rw-r--r-- 1 root          root     925 Dec  9 11:36 ftmodule.h
-rw-r--r-- 1 root          root     300 Dec  9 17:10 ftotval.lo
-rw-r--r-- 1 root          root   22124 Dec  9 17:10 ftotval.o
-rw-r--r-- 1 root          root     303 Dec  9 17:10 ftpatent.lo
-rw-r--r-- 1 root          root   16186 Dec  9 17:10 ftpatent.o
-rw-r--r-- 1 root          root     294 Dec  9 17:10 ftpfr.lo
-rw-r--r-- 1 root          root   26339 Dec  9 17:10 ftpfr.o
-rw-r--r-- 1 root          root     303 Dec  9 17:10 ftstroke.lo
-rw-r--r-- 1 root          root  127869 Dec  9 17:10 ftstroke.o
-rw-r--r-- 1 root          root     300 Dec  9 17:10 ftsynth.lo
-rw-r--r-- 1 root          root   19739 Dec  9 17:10 ftsynth.o
-rw-r--r-- 1 root          root     303 Dec  9 17:09 ftsystem.lo
-rw-r--r-- 1 root          root   14266 Dec  9 17:09 ftsystem.o
-rw-r--r-- 1 root          root     300 Dec  9 17:10 fttype1.lo
-rw-r--r-- 1 root          root   26792 Dec  9 17:10 fttype1.o
-rw-r--r-- 1 root          root     294 Dec  9 16:44 ftver.lo
-rw-r--r-- 1 root          root    1020 Dec  9 16:44 ftver.o
-rw-r--r-- 1 root          root     303 Dec  9 17:10 ftwinfnt.lo
-rw-r--r-- 1 root          root   21501 Dec  9 17:10 ftwinfnt.o
-rw-r--r-- 1 root          root     929 Dec  9 17:11 libfreetype.la
-rw-r--r-- 1 root          root     288 Dec  9 17:10 pcf.lo
-rw-r--r-- 1 root          root   93133 Dec  9 17:10 pcf.o
-rw-r--r-- 1 root          root     288 Dec  9 17:10 pfr.lo
-rw-r--r-- 1 root          root  151406 Dec  9 17:10 pfr.o
-rw-r--r-- 1 root          root     294 Dec  9 17:11 psaux.lo
-rw-r--r-- 1 root          root  447039 Dec  9 17:11 psaux.o
-rw-r--r-- 1 root          root     303 Dec  9 17:11 pshinter.lo
-rw-r--r-- 1 root          root  188038 Dec  9 17:11 pshinter.o
-rw-r--r-- 1 root          root     300 Dec  9 17:11 psnames.lo
-rw-r--r-- 1 root          root  106313 Dec  9 17:11 psnames.o
-rw-r--r-- 1 root          root     297 Dec  9 17:11 raster.lo
-rw-r--r-- 1 root          root   97808 Dec  9 17:11 raster.o
-rw-r--r-- 1 administrator users     80 Jan 19  2020 README
-rw-r--r-- 1 root          root     291 Dec  9 17:10 sfnt.lo
-rw-r--r-- 1 root          root  684892 Dec  9 17:10 sfnt.o
-rw-r--r-- 1 root          root     297 Dec  9 17:11 smooth.lo
-rw-r--r-- 1 root          root   75313 Dec  9 17:11 smooth.o
-rw-r--r-- 1 root          root     303 Dec  9 17:10 truetype.lo
-rw-r--r-- 1 root          root  493490 Dec  9 17:10 truetype.o
-rw-r--r-- 1 root          root     303 Dec  9 17:10 type1cid.lo
-rw-r--r-- 1 root          root  136873 Dec  9 17:10 type1cid.o
-rw-r--r-- 1 root          root     294 Dec  9 17:10 type1.lo
-rw-r--r-- 1 root          root  265266 Dec  9 17:10 type1.o
-rw-r--r-- 1 root          root     297 Dec  9 17:10 type42.lo
-rw-r--r-- 1 root          root  125160 Dec  9 17:10 type42.o
-rw-r--r-- 1 root          root     297 Dec  9 17:10 winfnt.lo
-rw-r--r-- 1 root          root   59958 Dec  9 17:10 winfnt.o
root@438242:~/freetype-2.10.4/objs# cd ..
root@438242:~/freetype-2.10.4# ls -l
total 6424
-rw-r--r--  1 root          root  382541 Dec  9 14:05 autofit.o
-rwxr-xr-x  1 administrator users   3935 Aug 31 08:26 autogen.sh
-rw-r--r--  1 root          root  119014 Dec  9 14:05 bdf.o
drwxr-xr-x 17 administrator users   4096 Dec  9 11:59 builds
-rw-r--r--  1 root          root  278555 Dec  9 14:05 cff.o
-rw-r--r--  1 administrator users 155426 Oct 20 06:13 ChangeLog
-rw-r--r--  1 administrator users  91563 Jan 19  2020 ChangeLog.20
-rw-r--r--  1 administrator users 329142 Aug 27 07:17 ChangeLog.21
-rw-r--r--  1 administrator users  99819 Jan 19  2020 ChangeLog.22
-rw-r--r--  1 administrator users 272330 Jan 19  2020 ChangeLog.23
-rw-r--r--  1 administrator users 207336 Jan 19  2020 ChangeLog.24
-rw-r--r--  1 administrator users 162296 Jan 19  2020 ChangeLog.25
-rw-r--r--  1 administrator users 176364 Jan 19  2020 ChangeLog.26
-rw-r--r--  1 administrator users  63133 Jan 19  2020 ChangeLog.27
-rw-r--r--  1 administrator users  96385 Jan 19  2020 ChangeLog.28
-rw-r--r--  1 administrator users  72091 Jan 19  2020 ChangeLog.29
-rw-r--r--  1 administrator users  18071 Oct 20 06:03 CMakeLists.txt
-rw-r--r--  1 root          root    1621 Dec  9 17:08 config.mk
-rwxr-xr-x  1 administrator users   4000 Mar 22  2020 configure
drwxr-xr-x  2 administrator users   4096 Oct 20 06:14 devel
drwxr-xr-x  3 administrator users   4096 Oct 20 06:15 docs
-rw-r--r--  1 root          root  390154 Dec  9 14:05 ftbase.o
-rw-r--r--  1 root          root   18132 Dec  9 14:05 ftbbox.o
-rw-r--r--  1 root          root   22134 Dec  9 14:05 ftbdf.o
-rw-r--r--  1 root          root   59435 Dec  9 14:05 ftbitmap.o
-rw-r--r--  1 root          root    8101 Dec  9 14:05 ftbzip2.o
-rw-r--r--  1 root          root  148317 Dec  9 14:05 ftcache.o
-rw-r--r--  1 root          root   23929 Dec  9 14:05 ftcid.o
-rw-r--r--  1 root          root    3461 Dec  9 14:04 ftdebug.o
-rw-r--r--  1 root          root   20832 Dec  9 14:05 ftfstype.o
-rw-r--r--  1 root          root   26496 Dec  9 14:05 ftgasp.o
-rw-r--r--  1 root          root   41681 Dec  9 14:05 ftglyph.o
-rw-r--r--  1 root          root   23414 Dec  9 14:05 ftgxval.o
-rw-r--r--  1 root          root   95993 Dec  9 14:05 ftgzip.o
-rw-r--r--  1 root          root   24934 Dec  9 14:05 ftinit.o
-rw-r--r--  1 root          root   34144 Dec  9 14:05 ftlzw.o
-rw-r--r--  1 root          root   40840 Dec  9 14:05 ftmm.o
-rw-r--r--  1 root          root   21284 Dec  9 14:05 ftotval.o
-rw-r--r--  1 root          root   16070 Dec  9 14:05 ftpatent.o
-rw-r--r--  1 root          root   24625 Dec  9 14:05 ftpfr.o
-rw-r--r--  1 root          root  109919 Dec  9 14:05 ftstroke.o
-rw-r--r--  1 root          root   19451 Dec  9 14:05 ftsynth.o
-rw-r--r--  1 root          root   13956 Dec  9 14:04 ftsystem.o
-rw-r--r--  1 root          root   26508 Dec  9 14:05 fttype1.o
-rw-r--r--  1 root          root   21129 Dec  9 14:05 ftwinfnt.o
drwxr-xr-x  3 administrator users   4096 Oct 20 06:14 include
-rw-r--r--  1 administrator users    846 Dec  9 11:40 Makefile
-rw-r--r--  1 administrator users  10876 Sep 22 18:55 meson.build
-rw-r--r--  1 administrator users   1351 Sep 21 06:53 meson_options.txt
-rw-r--r--  1 administrator users   6398 Aug 24 21:21 modules.cfg
drwxr-xr-x  3 administrator users   4096 Dec  9 17:11 objs
-rw-r--r--  1 root          root   86591 Dec  9 14:05 pcf.o
-rw-r--r--  1 root          root  143663 Dec  9 14:05 pfr.o
-rw-r--r--  1 root          root  412090 Dec  9 14:05 psaux.o
-rw-r--r--  1 root          root  167320 Dec  9 14:05 pshinter.o
-rw-r--r--  1 root          root  104294 Dec  9 14:05 psnames.o
-rw-r--r--  1 root          root   91462 Dec  9 14:05 raster.o
-rw-r--r--  1 administrator users   2826 Oct 20 06:03 README
-rw-r--r--  1 administrator users   1613 Aug 31 08:26 README.git
-rw-r--r--  1 root          root  510820 Dec  9 14:05 sfnt.o
-rw-r--r--  1 root          root   74655 Dec  9 14:05 smooth.o
drwxr-xr-x 26 administrator users   4096 Oct 20 06:14 src
-rw-r--r--  1 root          root  464753 Dec  9 14:05 truetype.o
-rw-r--r--  1 root          root  131073 Dec  9 14:05 type1cid.o
-rw-r--r--  1 root          root  220438 Dec  9 14:05 type1.o
-rw-r--r--  1 root          root  122610 Dec  9 14:05 type42.o
-rw-r--r--  1 administrator users    236 Jan 19  2020 version.sed
-rw-r--r--  1 administrator users  36034 Jan 19  2020 vms_make.com
-rw-r--r--  1 root          root   57720 Dec  9 14:05 winfnt.o
Edit: In relation to CMake - this is not something that I am familiar with at all. I do not know how, if at all, this handles cross-compilation and libraries, or on which server(s) that it runs. I am not sure whether I am relying on third party servers which might be shut down at any time in order to run this, or whether I can run my own CMake server on Bridgwater-Brunel, and, if so, how much work that it would take to set this up.
Learning an entirely new build system from scratch would take an unknown amount of time and might indefinitely postpone all work on Simutrans-Extended if the amount of time that it requires becomes extreme, as I can forsee that it might well. Embarking on a project with no idea at all of whether it can be completed within any reasonable time is best avoided.

If there are those who are willing and able to assist in setting up a CMake system, preferably to run alongside the existing compiling system to allow sufficient redundancy, this might be another matter, depending on the level of assistance that they are able to provide.

Offline TurfIt

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 1434
Re: Incorporating changes from Standard
« Reply #279 on: December 09, 2020, 05:49:08 PM »
Missing '--build=' triple, although it's detecting 'x86_64-pc-linux-gnu' which if correct is ok.
Missing pkgconfig "checking pkg-config is at least version 0.24... Please install dpkg-dev to use pkg-config when cross-building no" OK if you want to have to specify paths all the time rather than letting it "just work"
Missing way more than just harfbuzz:
Code: [Select]
Library configuration:
  external zlib: no
  bzip2:         no
  libpng:        yes (libpng-config)
  harfbuzz:      no
  brotli:        no
  image you need atleast zlib, as does Simutrans itself.
Missing 'make install' after 'make' ?  Again ok if you want a path mess. And will put things where you've specified with '--prefix=' which needs to be set for wherever your cross toolchain uses.  (/usr/x86_64-w64-mingw32/ maybe?)
LDFLAGS shouldn't need explicit setting if done "right". paths come from freetype2.pc via pkg-config called in makefile. (although you might still have freetype-config in there which may/may not work, so can just override in your config.mingw.  i.e. FREETYPE_CONFIG = pkg-config freetype2
And do note the libs are in objs/.libs after building freetype (before make/install does its thing...)
« Last Edit: December 09, 2020, 06:05:10 PM by TurfIt »