Add builder for SDL2_ttf #123

giordano · 2019-10-07T21:14:15Z

Ref #122. I consumed all my energy to make this build for FreeBSD, then I gave up when I arrived on Windows. It doesn't build the shared library, only the static archive.

I had the same problem with FreeBSD and I had to patch configure.in and (repeatedly) rebuild configure, but apparently this isn't sufficient for Windows. The patch is inspired by https://git.archlinux.org/svntogit/packages.git/tree/trunk/freetype-pkgconfig.patch?h=packages/sdl2_ttf.

giordano · 2019-10-26T14:05:58Z

I think the issue on Windows is that SDL2 is not building the shared library libSDL2main.dll, as I get this warnings when building SDL2_ttf:

/bin/sh ./libtool  --tag=CC   --mode=link cc  -g -O2 -I/workspace/destdir/include/freetype2 -I/workspace/destdir/include   -DHAVE_OPENGL -no-undefined -release 2.0 -version-info 14:1:14 -Wl,version.o  -o libSDL2_ttf.la -rpath /workspace/destdir/lib SDL_ttf.lo  -L/workspace/destdir/lib -lfreetype  -L/workspace/destdir/lib -lmingw32 -lSDL2main -lSDL2 -mwindows 

*** Warning: This system cannot link to static lib archive /workspace/destdir/lib/libSDL2main.la.
*** 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.

*** Warning: linker path does not have real file for library -lmingw32.
*** 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 libmingw32 and none of the candidates passed a file format test
*** using a file magic. Last file checked: /opt/x86_64-w64-mingw32/x86_64-w64-mingw32/sys-root/lib/libmingw32.a

*** Warning: linker path does not have real file for library -ldxguid.
*** 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 libdxguid and none of the candidates passed a file format test
*** using a file magic. Last file checked: /opt/x86_64-w64-mingw32/x86_64-w64-mingw32/sys-root/lib/libdxguid.a

*** Warning: linker path does not have real file for library -ldxerr8.
*** 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 libdxerr8 and none of the candidates passed a file format test
*** using a file magic. Last file checked: /opt/x86_64-w64-mingw32/x86_64-w64-mingw32/sys-root/lib/libdxerr8.a

*** Warning: linker path does not have real file for library -luuid.
*** 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 libuuid and none of the candidates passed a file format test
*** using a file magic. Last file checked: /opt/x86_64-w64-mingw32/x86_64-w64-mingw32/sys-root/lib/libuuid.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.

In the log file of SDL2 for Windows I found:

  LTLINK build/libSDL2main.la
libtool: link: warning: undefined symbols not allowed in x86_64-w64-mingw32 shared libraries
  LTLINK build/libSDL2_test.la
libtool: link: warning: undefined symbols not allowed in x86_64-w64-mingw32 shared libraries
  LTLINK build/libSDL2.la

*** Warning: Linking the shared library build/libSDL2.la against the non-libtool
*** objects  build/version.o is not portable!

libSDL2main.a has a few undefined symbols:

# nm libSDL2main.a 

SDL_windows_main.o:
0000000000000000 b .bss
0000000000000000 d .data
0000000000000000 N .debug_abbrev
0000000000000000 N .debug_aranges
0000000000000000 N .debug_frame
0000000000000000 N .debug_info
0000000000000000 N .debug_line
0000000000000000 N .debug_loc
0000000000000000 N .debug_ranges
0000000000000000 N .debug_str
0000000000000000 p .pdata
0000000000000000 r .rdata
0000000000000000 r .rdata$zzz
0000000000000000 t .text
0000000000000000 r .xdata
                 U SDL_SetMainReady
                 U SDL_ShowSimpleMessageBox
                 U SDL_main
0000000000000380 T WinMain
                 U __imp_GetCommandLineW
                 U __imp_VirtualAlloc
                 U __imp_VirtualFree
                 U __imp_WideCharToMultiByte
0000000000000360 T console_ansi_main
0000000000000370 T console_wmain
0000000000000000 t main_getcmdline

Most of them are in SDL2.dll, I have no clue where SDL_main should be

giordano · 2019-11-29T05:33:20Z

If no one comes up with some ideas, next week I'll probably try asking for help in https://discourse.libsdl.org/

NHDaly · 2019-12-03T17:39:27Z

Hmm.. I actually don't think SDL_ttf should be depending on libSDL2main at all. In their build notes (https://wiki.libsdl.org/Installation#Windows_XP.2FVista.2F7), they mention:

SDLmain [is] the small static .lib file that optionally provides WinMain().
and, then, in how to use the prebuilt libraries:
Unzip the archive, point your project at its "include" directory for headers, and link against SDL2.lib (and optionally, SDLmain.lib if you want SDL to provide a WinMain() that calls your standard Unix-like main() function)

I think that's something that users link against in their final applications if they are happy with the "standard" initialization of SDL...

But i dunno, reading your script, it looks like you just run SDL_ttf's configure and make, so maybe i'm wrong about that. Maybe it does need it for some weird reason.

Most of them are in SDL2.dll, I have no clue where SDL_main should be

SDL_main should be defined in the user's program. It's the "hook" to start up the user's code once SDL is initialized a bit (via the above main() function in SDLmain). Actually, it's even worse than that: you just write a regular main() function, but if you've done #include "SDL.h", they define a macro that redefines main to SDL_main 😂.

But yeah it seems plausible that the problem is SDL2_jll is not building .dlls like it should?

NHDaly · 2019-12-03T17:44:05Z

Oh, yeah, actually, i just downloaded the release generated for windows on SDL2_jll.jl, and it seems wrong to me:
https://github.com/JuliaBinaryWrappers/SDL2_jll.jl/releases

(~/Downloads/SDL2.v2.0.10.x86_64-w64-mingw32) $ tree bin lib
bin
├── SDL2.dll
└── sdl2-config
lib
├── cmake
│   └── SDL2
│       └── sdl2-config.cmake
├── libSDL2.dll.a
├── libSDL2.la
├── libSDL2_test.a
├── libSDL2_test.la
├── libSDL2main.a
├── libSDL2main.la
└── pkgconfig
    └── sdl2.pc

It seems like lib contains a bunch of artifacts of the build process, and the actual shared library SDL2.dll is in bin when it should be in lib? Or am I wrong in my understanding of how the products are supposed to look?
And there is no SDL2main.dll like there probably should be.

So yeah, i think that's probably the problem!

EDIT:

Okay yeah i think my understanding is correct. For comparison, here's the product tree structure on linux:

tree bin lib
bin
└── sdl2-config
lib
├── cmake
│   └── SDL2
│       └── sdl2-config.cmake
├── libSDL2-2.0.so.0 -> libSDL2-2.0.so.0.10.0
├── libSDL2-2.0.so.0.10.0
├── libSDL2.la
├── libSDL2.so -> libSDL2-2.0.so.0.10.0
├── libSDL2_test.a
├── libSDL2_test.la
├── libSDL2main.a
├── libSDL2main.la
└── pkgconfig
    └── sdl2.pc

Unfortunately I'm not able to look into this any time soon, but I think that's the problem that needs to be fixed! :)

staticfloat · 2019-12-03T17:49:44Z

the actual shared library SDL2.dll is in bin when it should be in lib?

On Windows, DLL's go into bin, not lib.

NHDaly · 2019-12-03T17:54:54Z

the actual shared library SDL2.dll is in bin when it should be in lib?

On Windows, DLL's go into bin, not lib.

Ah, thanks @staticfloat. Okay so then i think the problem is probably just that we're not building SDL2main.so / SDL2main.dll, but SDL2_ttf wants it. The .a file is there, but the final shared lib is not. Do we just need to add it to the list of expected products?:

Yggdrasil/S/SDL2/build_tarballs.jl

Line 38 in 3215e29

LibraryProduct(["libSDL2", "SDL2"], :libsdl2)

staticfloat · 2019-12-03T17:56:47Z

If it's not getting built, that's something that needs to be configured within the build itself; some kind of configure option or something like that.

NHDaly · 2019-12-04T15:36:00Z

I tried looking into this a bit yesterday but didn't immediately figure out how to get it to build. @giordano I think asking on the SDL discourse sounds like a great next step. Thanks for owning this!! 👍

giordano · 2019-12-21T08:35:40Z

I opened a thread in Sdl2 discourse, but so far I didn't get a reply.

However, I found something interesting:

It looks like these PKGBUILD files are the same as those in https://github.com/msys2/MINGW-packages, and they don't seem to be much different from what we're doing, maybe it's a matter of properly setting up the environment? However, having those PKGBUILD files in aur means that they can relatively easily be tested on arch Linux (which I happen to use, but for this task I'd go with a container, to avoid messing up with my system)

NHDaly · 2019-12-28T11:23:35Z

Hmm, yeah, examining those build files, they just do a make / make install...

Could it be that the flags you're adding are screwing it up somehow?: --enable-shared and --disable-static? Why can't we just use the defaults there?

NHDaly · 2019-12-28T11:37:13Z

Aha! After rereading this thread, and googling the warning message you highlighted that prevented building libSDL2main.dll, I came across this:
Ancurio/SDL_sound#3

Looks like they fixed that here:
Ancurio/SDL_sound#4

I wonder if we can fix this by adding -no-undefined to the build rules for SDL2main in SDL2_jll.jl?
Looks like maybe we need to add a Makefile.am, and specify it there?:
https://stackoverflow.com/questions/15156868/passing-no-undefined-to-libtool-ldflag

(Ah, and since this confused me: -no-undefined means "disable the undefined warning," which allows you to build the shared library despite it containing references to undefined functions [since that's expected]. It confused me since it sounds like it means "disallow undefined", not "disable the undefined warning". 🤷‍♂ Compiler flags, man. https://stackoverflow.com/a/22884787/751061)

giordano · 2019-12-28T11:42:40Z

Good catch! I'll play with -no-undefined

giordano · 2019-12-28T11:45:57Z

Ok, you've been too fast for me 😅

NHDaly · 2019-12-28T11:49:59Z

Haha sorry! I was too impatient to try anything on the terminal, so i just edited the file in GitHub and fired it off to let CI test it out for me! 😅 haha

If this doesn't work i'll actually try it locally.... 😅

NHDaly · 2019-12-28T13:10:10Z

S/SDL2_ttf/bundled/patches/configure_in-v2.0.15.patch

+		LIBS="$LIBS $SDL2_LIBS"
+	],
+	sdl2_found=no
+ )
+-CFLAGS="$CFLAGS $SDL_CFLAGS"
+-LIBS="$LIBS $SDL_LIBS"


@giordano Is there any reason why you changed these variable names?: SDL_LIBS to SDL2_LIBS and SDL_CFLAGS to SDL22_CFLAGS?

It looks like probably a find-and-replace mistake to me?
I'm wondering if somehow because you're not specifying the libs here, maybe it's defaulting to "all the libs it can find" or something dumb, and that's why it's picking up SDL2main from SDL2_jll?

About the why I changed the name of the variables: I think that the way the default configure script was looking for SDL configuration was broken with our setup, I just switched to using the pkgconfig file, and since the module is called "SDL2" (see the first argument of PKG_CHECK_MODULES) the variables names will start with "SDL2".

S/SDL2_ttf/bundled/patches/configure_in-v2.0.15.patch

Co-Authored-By: Nathan Daly <[email protected]>

NHDaly · 2019-12-28T14:20:39Z

Relevant breadcrumbs to a related thread @giordano and I read when debugging:
libSDL2pp/libSDL2pp#66

Doesn't seem to contain any new info, but some good breakdowns of what the various WinMain, main and SDL_main are.
They fixed the problem by adding -lmingw32, but we already have that in our builds (automatically there, in the makefile generated by config)...

NHDaly · 2019-12-28T14:45:59Z

One possible clue: There are a lot more undefined symbols in libSDL2_ttf.a, so looking at SDL2_main might actually have been a red-herring:

sandbox:${WORKSPACE}/srcdir/SDL2_ttf-2.0.15 # nm /workspace/destdir/lib/libSDL2_ttf.a

SDL_ttf.o:
0000000000000000 b .bss
0000000000000000 d .data
0000000000000000 N .debug_abbrev
0000000000000000 N .debug_aranges
0000000000000000 N .debug_frame
0000000000000000 N .debug_info
0000000000000000 N .debug_line
0000000000000000 N .debug_loc
0000000000000000 N .debug_ranges
0000000000000000 N .debug_str
0000000000000000 i .drectve
0000000000000000 p .pdata
0000000000000000 r .rdata
0000000000000000 r .rdata$zzz
0000000000000000 t .text
0000000000000000 r .xdata
                 U FT_Done_Face
                 U FT_Done_FreeType
                 U FT_Done_Glyph
                 U FT_Get_Char_Index
                 U FT_Get_Glyph
                 U FT_Get_Kerning
                 U FT_Glyph_Stroke
                 U FT_Glyph_To_Bitmap
                 U FT_Init_FreeType
                 U FT_Load_Glyph
                 U FT_MulFix
                 U FT_Open_Face
                 U FT_Outline_Transform
                 U FT_Render_Glyph
                 U FT_Select_Size
                 U FT_Set_Char_Size
                 U FT_Set_Charmap
                 U FT_Stroker_Done
                 U FT_Stroker_New
                 U FT_Stroker_Set
0000000000000530 t Find_Glyph
00000000000004f0 t Flush_Cache
00000000000004a0 t Flush_Glyph
0000000000000290 t RWread
                 U SDL_CreateRGBSurface
                 U SDL_Error
                 U SDL_FillRect
                 U SDL_FreeSurface
                 U SDL_RWFromFile
                 U SDL_RWclose
                 U SDL_RWread
                 U SDL_RWseek
                 U SDL_RWsize
                 U SDL_RWtell
                 U SDL_SetColorKey
                 U SDL_SetError
                 U SDL_SetSurfaceBlendMode
                 U SDL_ceilf
                 U SDL_free
                 U SDL_malloc
                 U SDL_memcpy
                 U SDL_memset
                 U SDL_realloc
                 U SDL_strchr
                 U SDL_strlcpy
                 U SDL_strlen
00000000000010f0 T TTF_ByteSwappedUNICODE
0000000000001160 T TTF_CloseFont
00000000000015b0 T TTF_FontAscent
00000000000015c0 T TTF_FontDescent
0000000000001630 T TTF_FontFaceFamilyName
0000000000001620 T TTF_FontFaceIsFixedWidth
0000000000001640 T TTF_FontFaceStyleName
0000000000001610 T TTF_FontFaces
00000000000015a0 T TTF_FontHeight
00000000000015d0 T TTF_FontLineSkip
0000000000003710 T TTF_GetFontHinting
00000000000015e0 T TTF_GetFontKerning
0000000000003790 T TTF_GetFontKerningSize
00000000000037c0 T TTF_GetFontKerningSizeGlyphs
00000000000036c0 T TTF_GetFontOutline
0000000000003680 T TTF_GetFontStyle
0000000000001650 T TTF_GlyphIsProvided
0000000000001660 T TTF_GlyphMetrics
0000000000001100 T TTF_Init
00000000000010d0 T TTF_Linked_Version
0000000000001590 T TTF_OpenFont
0000000000001550 T TTF_OpenFontIndex
00000000000011e0 T TTF_OpenFontIndexRW
0000000000001540 T TTF_OpenFontRW
0000000000003750 T TTF_Quit
00000000000035f0 T TTF_RenderGlyph_Blended
0000000000002540 T TTF_RenderGlyph_Shaded
0000000000001e20 T TTF_RenderGlyph_Solid
0000000000002990 T TTF_RenderText_Blended
0000000000003420 T TTF_RenderText_Blended_Wrapped
0000000000002370 T TTF_RenderText_Shaded
0000000000001c70 T TTF_RenderText_Solid
0000000000002a60 T TTF_RenderUNICODE_Blended
0000000000003500 T TTF_RenderUNICODE_Blended_Wrapped
0000000000002450 T TTF_RenderUNICODE_Shaded
0000000000001d40 T TTF_RenderUNICODE_Solid
0000000000002590 T TTF_RenderUTF8_Blended
0000000000002b40 T TTF_RenderUTF8_Blended_Wrapped
0000000000001e70 T TTF_RenderUTF8_Shaded
0000000000001940 T TTF_RenderUTF8_Solid
00000000000036d0 T TTF_SetFontHinting
00000000000015f0 T TTF_SetFontKerning
0000000000003690 T TTF_SetFontOutline
0000000000003640 T TTF_SetFontStyle
0000000000001720 T TTF_SizeText
0000000000001830 T TTF_SizeUNICODE
0000000000001810 T TTF_SizeUTF8
0000000000000e50 t TTF_SizeUTF8_Internal
0000000000003780 T TTF_WasInit
0000000000000004 b TTF_byteswapped
0000000000001080 t TTF_drawLine.isra.2
00000000000002e0 t TTF_initFontMetrics
0000000000000008 b TTF_initialized
0000000000000040 t UCS2_to_UTF8
0000000000000110 t UTF8_getch
0000000000000010 b library
0000000000000000 b linked_version.14107
sandbox:${WORKSPACE}/srcdir/SDL2_ttf-2.0.15 # nm /workspace/destdir/lib/libSDL2main.a

SDL_windows_main.o:
0000000000000000 b .bss
0000000000000000 d .data
0000000000000000 N .debug_abbrev
0000000000000000 N .debug_aranges
0000000000000000 N .debug_frame
0000000000000000 N .debug_info
0000000000000000 N .debug_line
0000000000000000 N .debug_loc
0000000000000000 N .debug_ranges
0000000000000000 N .debug_str
0000000000000000 p .pdata
0000000000000000 r .rdata
0000000000000000 r .rdata$zzz
0000000000000000 t .text
0000000000000000 r .xdata
                 U SDL_SetMainReady
                 U SDL_ShowSimpleMessageBox
                 U SDL_main
0000000000000380 T WinMain
                 U __imp_GetCommandLineW
                 U __imp_VirtualAlloc
                 U __imp_VirtualFree
                 U __imp_WideCharToMultiByte
0000000000000360 T console_ansi_main
0000000000000370 T console_wmain
0000000000000000 t main_getcmdline
sandbox:${WORKSPACE}/srcdir/SDL2_ttf-2.0.15 #

giordano · 2019-12-28T15:15:15Z

To summarise, the problems were:

my wrong patch (interesting that it worked for all other platforms 😂)
something broken with the test executables for Windows (but we don't care about them)
when building for Windows only the static library was built despite asking configure to do so, we had to manually build the shared one

NHDaly

Love it. Great work. Thanks for the summary too! :)

Add builder for SDL2_ttf

3215e29

giordano added multimedia 🎧 Issues and builders related to multimedia libraries Windows 🙄 Doesn't build for Windows labels Oct 7, 2019

giordano mentioned this pull request Oct 10, 2019

Use binaries from JuliaBinaryWrappers NHDaly/SimpleDirectMediaLayer.jl#5

Closed

staticfloat closed this Nov 8, 2019

staticfloat reopened this Nov 8, 2019

giordano closed this Nov 29, 2019

giordano reopened this Nov 29, 2019

giordano mentioned this pull request Nov 29, 2019

Add SDL2 plugins ? #122

Closed

giordano added the long shot 🏹 This is going to be fun label Dec 17, 2019

NHDaly mentioned this pull request Dec 28, 2019

SDL2: Add -no-undefined to LD_FLAGS for libSDL2main #340

Closed

NHDaly reviewed Dec 28, 2019

View reviewed changes

S/SDL2_ttf/bundled/patches/configure_in-v2.0.15.patch Outdated Show resolved Hide resolved

Update S/SDL2_ttf/bundled/patches/configure_in-v2.0.15.patch

c4d4c5e

Co-Authored-By: Nathan Daly <[email protected]>

giordano added 2 commits December 28, 2019 15:47

[SDL2_ttf] Don't build programs, they won't be installed anyway

034519c

[SDL2_ttf] Manually build the shared library for Windows

1cb4ec5

giordano marked this pull request as ready for review December 28, 2019 15:17

NHDaly approved these changes Dec 28, 2019

View reviewed changes

staticfloat approved these changes Dec 28, 2019

View reviewed changes

staticfloat merged commit 71e20c0 into JuliaPackaging:master Dec 28, 2019

giordano deleted the sdl2-ttf branch December 31, 2019 20:35

giordano mentioned this pull request Jan 27, 2020

Wizard recipe: SDL2_gfx-v1.0.3 #438

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add builder for SDL2_ttf #123

Add builder for SDL2_ttf #123

giordano commented Oct 7, 2019

giordano commented Oct 26, 2019 •

edited

Loading

giordano commented Nov 29, 2019

NHDaly commented Dec 3, 2019

NHDaly commented Dec 3, 2019 •

edited

Loading

staticfloat commented Dec 3, 2019

NHDaly commented Dec 3, 2019

staticfloat commented Dec 3, 2019

NHDaly commented Dec 4, 2019

giordano commented Dec 21, 2019 •

edited

Loading

NHDaly commented Dec 28, 2019

NHDaly commented Dec 28, 2019

giordano commented Dec 28, 2019

giordano commented Dec 28, 2019

NHDaly commented Dec 28, 2019

NHDaly Dec 28, 2019

giordano Dec 28, 2019

NHDaly commented Dec 28, 2019

NHDaly commented Dec 28, 2019

giordano commented Dec 28, 2019

NHDaly left a comment

Add builder for SDL2_ttf #123

Add builder for SDL2_ttf #123

Conversation

giordano commented Oct 7, 2019

giordano commented Oct 26, 2019 • edited Loading

giordano commented Nov 29, 2019

NHDaly commented Dec 3, 2019

NHDaly commented Dec 3, 2019 • edited Loading

staticfloat commented Dec 3, 2019

NHDaly commented Dec 3, 2019

staticfloat commented Dec 3, 2019

NHDaly commented Dec 4, 2019

giordano commented Dec 21, 2019 • edited Loading

NHDaly commented Dec 28, 2019

NHDaly commented Dec 28, 2019

giordano commented Dec 28, 2019

giordano commented Dec 28, 2019

NHDaly commented Dec 28, 2019

NHDaly Dec 28, 2019

Choose a reason for hiding this comment

giordano Dec 28, 2019

Choose a reason for hiding this comment

NHDaly commented Dec 28, 2019

NHDaly commented Dec 28, 2019

giordano commented Dec 28, 2019

NHDaly left a comment

Choose a reason for hiding this comment

giordano commented Oct 26, 2019 •

edited

Loading

NHDaly commented Dec 3, 2019 •

edited

Loading

giordano commented Dec 21, 2019 •

edited

Loading