Menu

#149 Fix build with -flto

xfig
closed
nobody
patch (1)
2023-08-25
2022-08-27
Matt Turner
No

Patch to fix build with -lfto.

1 Attachments

Discussion

  • tkl

    tkl - 2022-08-27

    This might be an issue with gcc, not with clang. Anyhow, applied with commit [5b5bce].

     

    Related

    Commit: [5b5bce]

  • tkl

    tkl - 2022-08-27
    • status: open --> pending
     
  • tkl

    tkl - 2022-08-27

    This might be an issue with gcc, not with clang. Anyhow, applied with commit [5b5bce].

     

    Related

    Commit: [5b5bce]

  • Stefan Brüns

    Stefan Brüns - 2023-03-09

    libxfig.a contains src/main.c, and the test binaries are linked to libxfig, thus there are two definitions for "main". It would probably be better to leave src/main.c out of libxfig to avoid any ambiguities.

    You are relying on specific linker behavior, and you force it to not complain about multiple definitions: '-Wl,--allow-multiple-definitions'.

     
    • tkl

      tkl - 2023-03-10

      Right, the "-Wl,--allow-multiple-definitions" option was a quick fix, in my environment, to make the test binaries compile and have the linker find any symbols that are requested in the test binaries, most possibly requested indirectly by recursion.

      Leaving src/main.c out is not really an option, since a lot of globals are defined there. (Not a good design, I know.) A viable and still not overly laborious alternative is to replace main() by xfigmain(), "sed 's/^main(/xfigmain(/ main.c' >libxfigmain.c" and compile the convenience library libxfig.a with libxfigmain.c in place of main.c. This approach is probably a cleaner solution than reliance on linker properties, and it will be implemented soon.

       
  • tkl

    tkl - 2023-08-25
    • status: pending --> closed
     

Log in to post a comment.