Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Autotools build doesn't work on OSX #796

Closed
slime73 opened this issue Nov 11, 2013 · 14 comments
Closed

Autotools build doesn't work on OSX #796

slime73 opened this issue Nov 11, 2013 · 14 comments
Labels
bug Something isn't working

Comments

@slime73
Copy link
Member

slime73 commented Nov 11, 2013

Original report by ryandesign (Bitbucket: ryandesign, GitHub: ryandesign).

After dealing with the other reported OS X build failures, building recent LÖVE 8ca1af7a7ccd39844271a658c3498ebea7041980 with ./configure and make is failing on OS X 10.9 Mavericks as follows:

/bin/sh ../libtool  --tag=CXX   --mode=link /usr/bin/clang++ -D_THREAD_SAFE -I/opt/local/include/SDL2  -pipe -Os -arch x86_64 -stdlib=libc++ -std=c++11  -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -o love love.o liblove.la -lmpg123 -llua -lvorbisfile -lmodplug -lphysfs -lfreetype -lIL -lopenal -lGL 

*** Warning: Linking the executable love against the loadable module
*** liblove.so is not portable!
*** Warning: lib liblove.so is a module, not a shared library
libtool: link: /usr/bin/clang++ -D_THREAD_SAFE -I/opt/local/include/SDL2 -pipe -Os -arch x86_64 -stdlib=libc++ -std=c++11 -Wl,-headerpad_max_install_names -arch x86_64 -o .libs/love love.o  -L/opt/local/lib ./.libs/liblove.a -lSDL2 -lmpg123 -llua -lvorbisfile -lmodplug -lphysfs -lfreetype -lIL -lopenal -lGL
Undefined symbols for architecture x86_64:
  "_CFBundleCreate", referenced from:
      ___GLeeGetProcAddress in liblove.a(GLee.o)
  "_CFBundleGetFunctionPointerForName", referenced from:
      ___GLeeGetProcAddress in liblove.a(GLee.o)
  "_CFRelease", referenced from:
      ___GLeeGetProcAddress in liblove.a(GLee.o)
  "_CFStringCreateWithCString", referenced from:
      ___GLeeGetProcAddress in liblove.a(GLee.o)
  "_CFURLCreateWithFileSystemPath", referenced from:
      ___GLeeGetProcAddress in liblove.a(GLee.o)
  "love::osx::checkDropEvents()", referenced from:
      _main in love.o
  "love::osx::getLoveInResources()", referenced from:
      _main in love.o
  "___CFConstantStringClassReference", referenced from:
      CFString in liblove.a(GLee.o)
  "_kCFAllocatorDefault", referenced from:
      ___GLeeGetProcAddress in liblove.a(GLee.o)
ld: symbol(s) not found for architecture x86_64

The "CF" symbols are from the Core Foundation framework; adding -framework CoreFoundation to $LDFLAGS fixes this. That leaves only:

/bin/sh ../libtool  --tag=CXX   --mode=link /usr/bin/clang++ -D_THREAD_SAFE -I/opt/local/include/SDL2  -pipe -Os -arch x86_64 -stdlib=libc++ -std=c++11  -L/opt/local/lib -Wl,-headerpad_max_install_names -framework CoreFoundation -arch x86_64 -o love love.o liblove.la -lmpg123 -llua -lvorbisfile -lmodplug -lphysfs -lfreetype -lIL -lopenal -lGL 

*** Warning: Linking the executable love against the loadable module
*** liblove.so is not portable!
*** Warning: lib liblove.so is a module, not a shared library
libtool: link: /usr/bin/clang++ -D_THREAD_SAFE -I/opt/local/include/SDL2 -pipe -Os -arch x86_64 -stdlib=libc++ -std=c++11 -Wl,-headerpad_max_install_names -arch x86_64 -o .libs/love love.o  -L/opt/local/lib ./.libs/liblove.a -lSDL2 -lmpg123 -llua -lvorbisfile -lmodplug -lphysfs -lfreetype -lIL -lopenal -lGL -framework CoreFoundation
Undefined symbols for architecture x86_64:
  "love::osx::checkDropEvents()", referenced from:
      _main in love.o
  "love::osx::getLoveInResources()", referenced from:
      _main in love.o
ld: symbol(s) not found for architecture x86_64
@slime73
Copy link
Member Author

slime73 commented Nov 11, 2013

Original comment by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).

I would assume these are in platform/macosx/OSX.mm, which is obviously not built (like OSX.h).

@slime73
Copy link
Member Author

slime73 commented Nov 11, 2013

Original comment by ryandesign (Bitbucket: ryandesign, GitHub: ryandesign).

OSX.h is being included because I added -I../platform/macosx to $CPPFLAGS, but the log does not mention OSX.mm so yes a rule to build that probably needs to be added somewhere.

@slime73
Copy link
Member Author

slime73 commented Nov 11, 2013

Original comment by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).

The easiest place to (manually) do this is in platform/unix/gen-makefile, in the static parts of it.
That said, I do have a branch in love-experiments (moduleselect) where I'm reworking the current autotools workflow, I'll see if I can get some OSX support in there next time I work on it.

@slime73
Copy link
Member Author

slime73 commented Nov 11, 2013

Original comment by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).

Alright, I just committed to moduleselect, could you try compiling using that and the --enable-osx flag? It should automatically add the -framework flag, and compile OSX.mm.. and hopefully it also does the include right.

If it doesn't do everything needed to build on osx, do tell, I don't have a machine to test this with.

@slime73
Copy link
Member Author

slime73 commented Nov 11, 2013

Original comment by ryandesign (Bitbucket: ryandesign, GitHub: ryandesign).

Thanks, I tried https://bitbucket.org/bartbes/love-experiments/commits/8bed4af77d342906ae8bfa058b0020b7683786a7. You use GNU-specific features of find, head and sed which are not available in the OS X (BSD) versions of those utilities, so I had to install the coreutils, findutils and gsed MacPorts ports and use those versions instead.

After dealing with #793, it failed with:

libtool: link: ccache /usr/bin/clang++ -pipe -Os -arch x86_64 -stdlib=libc++ -Wl,-headerpad_max_install_names -arch x86_64 -o .libs/love love.o ../platform/macosx/OSX.o  -L/opt/local/lib ./.libs/liblove.a -lSDL2 -lmpg123 -llua -lvorbisfile -lmodplug -lphysfs -lfreetype -lIL -lopenal -lGL -framework CoreFoundation
Undefined symbols for architecture x86_64:
  "_OBJC_CLASS_$_NSBundle", referenced from:
      objc-class-ref in OSX.o
  "_objc_msgSend", referenced from:
      love::osx::getLoveInResources() in OSX.o
  "_objc_msgSend_fixup", referenced from:
      l_objc_msgSend_fixup_count in OSX.o
      l_objc_msgSend_fixup_objectAtIndex_ in OSX.o
ld: symbol(s) not found for architecture x86_64

Adding -framework Cocoa to the $LDFLAGS as well allows it to compile.

@slime73
Copy link
Member Author

slime73 commented Nov 11, 2013

Original comment by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).

So.. the gnu-specific feature of head is negative counts, I guess, but the ones from find and sed I don't know, could you tell me what those are?

Also, keep in mind that automagic only needs to be run if you're using the repo version, so I guess the gnu utils aren't needed for source distributions.

@slime73
Copy link
Member Author

slime73 commented Nov 11, 2013

Original comment by ryandesign (Bitbucket: ryandesign, GitHub: ryandesign).

Yes, negative counts aren't supported in BSD head. BSD find doesn't support -printf. BSD sed turned the \t not into a tab but into the literal character t.

@slime73
Copy link
Member Author

slime73 commented Nov 11, 2013

Original comment by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).

Alright, Cocoa added and hopefully I fixed the bsd userland issues with automagic as well.

@slime73
Copy link
Member Author

slime73 commented Nov 11, 2013

Original comment by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).

#795 was marked as a duplicate of this issue.

@slime73
Copy link
Member Author

slime73 commented Nov 11, 2013

Original comment by ryandesign (Bitbucket: ryandesign, GitHub: ryandesign).

Thanks. I now have:

[automagic]  Running genmodules...
Generating src/Makefile.am ...
platform/unix/genmodules: line 49: -2: substring expression < 0
platform/unix/genmodules: line 145: src/Makefile.am: No such file or directory
src/Makefile.am is updated! ^.^

@slime73
Copy link
Member Author

slime73 commented Nov 11, 2013

Original comment by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).

OSX and its GPLv3 hate. I just committed a version that actually calculates the length parameter using the string length, which should work fine if the contents of a dir are non-empty.

crosses fingers

@slime73
Copy link
Member Author

slime73 commented Nov 12, 2013

Original comment by ryandesign (Bitbucket: ryandesign, GitHub: ryandesign).

Works fine! Thanks.

Will that branch be merged to the mainline soon?

Can I continue to report other issues here, even though I'm not using the mainline code?

@slime73
Copy link
Member Author

slime73 commented Nov 13, 2013

Original comment by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).

Awesome, and sure, the only change in that particular branch is the build system.

@slime73
Copy link
Member Author

slime73 commented Dec 8, 2013

Original comment by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).

Merged in

@slime73 slime73 closed this as completed Dec 8, 2013
@slime73 slime73 added minor bug Something isn't working labels Feb 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@slime73