Kitty: Linker fails with "-stack_size option can only be used when linking a main executable"

Created on 21 Jan 2018 · 6Comments · Source: kovidgoyal/kitty

Trying to build from source on macOS 10.13.2.

As soon as it gets to linking, it errors with -stack_size option can only be used when linking a main executable:

$ make debug
python3 setup.py build  --debug
CC: clang (4, 2)
Compiling kitty/unicode-data.c ...
Compiling kitty/state.c ...
Compiling kitty/shaders.c ...
Compiling kitty/screen.c ...
Compiling kitty/parser.c ...
Compiling kitty/mouse.c ...
Compiling kitty/line.c ...
Compiling kitty/line-buf.c ...
Compiling kitty/keys.c ...
Compiling kitty/history.c ...
Compiling kitty/graphics.c ...
Compiling kitty/glfw.c ...
Compiling kitty/glfw-wrapper.c ...
Compiling kitty/gl-wrapper.c ...
Compiling kitty/fonts.c ...
Compiling kitty/data-types.c ...
Compiling kitty/cursor.c ...
Compiling kitty/core_text.m ...
Compiling kitty/colors.c ...
Compiling kitty/cocoa_window.m ...
Compiling kitty/child.c ...
Compiling kitty/child-monitor.c ...
Compiling kitty/charsets.c ...
Compiling kitty/parser_dump.c ...
Linking kitty/fast_data_types ...
ld: -stack_size option can only be used when linking a main executable
clang: error: linker command failed with exit code 1 (use -v to see invocation)
clang -Wall -shared /Users/specious/c3/kitty/build/fast_data_types-unicode-data.c.o /Users/specious/c3/kitty/build/fast_data_types-state.c.o /Users/specious/c3/kitty/build/fast_data_types-shaders.c.o /Users/specious/c3/kitty/build/fast_data_types-screen.c.o /Users/specious/c3/kitty/build/fast_data_types-parser.c.o /Users/specious/c3/kitty/build/fast_data_types-mouse.c.o /Users/specious/c3/kitty/build/fast_data_types-line.c.o /Users/specious/c3/kitty/build/fast_data_types-line-buf.c.o /Users/specious/c3/kitty/build/fast_data_types-keys.c.o /Users/specious/c3/kitty/build/fast_data_types-history.c.o /Users/specious/c3/kitty/build/fast_data_types-graphics.c.o /Users/specious/c3/kitty/build/fast_data_types-glfw.c.o /Users/specious/c3/kitty/build/fast_data_types-glfw-wrapper.c.o /Users/specious/c3/kitty/build/fast_data_types-gl-wrapper.c.o /Users/specious/c3/kitty/build/fast_data_types-fonts.c.o /Users/specious/c3/kitty/build/fast_data_types-data-types.c.o /Users/specious/c3/kitty/build/fast_data_types-cursor.c.o /Users/specious/c3/kitty/build/fast_data_types-core_text.m.o /Users/specious/c3/kitty/build/fast_data_types-colors.c.o /Users/specious/c3/kitty/build/fast_data_types-cocoa_window.m.o /Users/specious/c3/kitty/build/fast_data_types-child.c.o /Users/specious/c3/kitty/build/fast_data_types-child-monitor.c.o /Users/specious/c3/kitty/build/fast_data_types-charsets.c.o /Users/specious/c3/kitty/build/fast_data_types-parser_dump.c.o -Wall -shared -ldl -framework CoreFoundation -L/Users/specious/miniconda3/lib -lpython3.6m -Wl,-stack_size,1000000 -framework CoreFoundation -framework CoreText -framework CoreGraphics -L/usr/local/Cellar/harfbuzz/1.7.4/lib -lharfbuzz -framework OpenGL -L/usr/local/Cellar/libpng/1.6.34/lib -lpng16 -lz -framework Cocoa -o /Users/specious/c3/kitty/kitty/fast_data_types.so
make: *** [debug] Error 1

$ clang --version
Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin17.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Source

specious

Most helpful comment

Yes, this has nothing to do with kitty, true. I'm glad I found this issue. Thanks for saving me some time investigating it.

I'm using Python 3.6.5 from pyenv, which apparently has the same issue as miniconda.

Still, in case anyone wants a _quick n' dirty_ change just to run make:

diff --git a/setup.py b/setup.py
index b9f0a57e..c6c79bb4 100755
--- a/setup.py
+++ b/setup.py
@@ -126,7 +126,7 @@ def get_python_flags(cflags):
         libs += [
             '-lpython' + sysconfig.get_config_var('VERSION') + sys.abiflags
         ]
-        libs += sysconfig.get_config_var('LINKFORSHARED').split()
+        libs += sysconfig.get_config_var('LINKFORSHARED').replace('-Wl,-stack_size,1000000', '').split()
     return libs

Just bear in mind this flag sanitization should not – and is not going to – be part of kitty.

scorphus on 26 Aug 2018

👍4

All 6 comments

kitty does not use -stack_size in its build. That is coming from some other component on your system, if I had to guess, miniconda. Use a python installed via brew instead and you will be fine.

kovidgoyal on 21 Jan 2018

You're totally right about that. Compiling with my brew-installed python 3.6 worked perfectly:

$ ls -l /usr/local/bin/python3.6
lrwxr-xr-x  1 specious  admin  39 Jan 19 02:26 /usr/local/bin/python3.6 -> ../Cellar/python3/3.6.4_2/bin/python3.6

$ /usr/local/bin/python3.6 setup.py --debug
CC: clang (4, 2)
Compiling kitty/unicode-data.c ...
Compiling kitty/state.c ...
Compiling kitty/shaders.c ...
Compiling kitty/screen.c ...
Compiling kitty/parser.c ...
Compiling kitty/mouse.c ...
Compiling kitty/line.c ...
Compiling kitty/line-buf.c ...
Compiling kitty/keys.c ...
Compiling kitty/history.c ...
Compiling kitty/graphics.c ...
Compiling kitty/glfw.c ...
Compiling kitty/glfw-wrapper.c ...
Compiling kitty/gl-wrapper.c ...
Compiling kitty/fonts.c ...
Compiling kitty/data-types.c ...
Compiling kitty/cursor.c ...
Compiling kitty/core_text.m ...
Compiling kitty/colors.c ...
Compiling kitty/cocoa_window.m ...
Compiling kitty/child.c ...
Compiling kitty/child-monitor.c ...
Compiling kitty/charsets.c ...
Compiling kitty/parser_dump.c ...
Linking kitty/fast_data_types ...
Compiling glfw/context.c ...
Compiling glfw/init.c ...
Compiling glfw/input.c ...
Compiling glfw/monitor.c ...
Compiling glfw/vulkan.c ...
Compiling glfw/window.c ...
Compiling glfw/cocoa_init.m ...
Compiling glfw/cocoa_joystick.m ...
Compiling glfw/cocoa_monitor.m ...
Compiling glfw/cocoa_window.m ...
Compiling glfw/cocoa_time.c ...
Compiling glfw/posix_thread.c ...
Compiling glfw/nsgl_context.m ...
Compiling glfw/egl_context.c ...
Compiling glfw/osmesa_context.c ...
Linking kitty/glfw-cocoa ...
Creating asan-launcher ...

I'm posting this because it might help people in a similar situation to navigate around this roadblock.

How would you feel about keeping this issue open until we figure out the best way to resolve this incompatibility in general?

specious on 21 Jan 2018

I dont see how this has anything to do with kitty. Basically miniconda is compiling python with the -stack_size option. It should remove that option from the generated sysconfig.py file, which is where flags used to compile python modules are stored and where applications like kitty that want to build python modules are supposed to read them from. I am not going to implement logic to try to sanitize the flags sysconfig.py supplies, since that is highly compiler dependent and a moving target.

kovidgoyal on 22 Jan 2018

Thank you for your insight, because I didn't have it.

Looks like we have two issues already upstream:

I understand what you're saying, that this is not a problem with Kitty. I do think this is a valuable situation to be able to look at with respect to the upstream issue, which in turn has relevance in terms of being a hindrance to potential users trying to install Kitty and having no clue why the build isn't succeeding.

specious on 25 Jan 2018

👍1

Yes, this has nothing to do with kitty, true. I'm glad I found this issue. Thanks for saving me some time investigating it.

I'm using Python 3.6.5 from pyenv, which apparently has the same issue as miniconda.

Still, in case anyone wants a _quick n' dirty_ change just to run make:

diff --git a/setup.py b/setup.py
index b9f0a57e..c6c79bb4 100755
--- a/setup.py
+++ b/setup.py
@@ -126,7 +126,7 @@ def get_python_flags(cflags):
         libs += [
             '-lpython' + sysconfig.get_config_var('VERSION') + sys.abiflags
         ]
-        libs += sysconfig.get_config_var('LINKFORSHARED').split()
+        libs += sysconfig.get_config_var('LINKFORSHARED').replace('-Wl,-stack_size,1000000', '').split()
     return libs

Just bear in mind this flag sanitization should not – and is not going to – be part of kitty.

scorphus on 26 Aug 2018

👍4

If you're using pyenv, a less invasive work-around might be to just run 'pyenv local system' in your kitty build area and call it a day :)

Worked great for me!