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.

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

[Bug] Linking when adding DEBOUNCE_TYPE other than default WhiteFox #8051

Closed
3 tasks
albertogg opened this issue Jan 31, 2020 · 4 comments
Closed
3 tasks

[Bug] Linking when adding DEBOUNCE_TYPE other than default WhiteFox #8051

albertogg opened this issue Jan 31, 2020 · 4 comments

Comments

@albertogg
Copy link
Contributor

albertogg commented Jan 31, 2020

Hi!, I'm getting an error while linking when changing the DEBOUNCE_TYPE to either eager_pr or eager_pk on the WhiteFox. This does not happen with sym_g. If there's anything else I can provide let me know.

My current rules.mk overrides options are:

BACKLIGHT_ENABLE  = no
BOOTMAGIC_ENABLE  = no
VISUALIZER_ENABLE = no
DEBOUNCE_TYPE     = eager_pk

The error I'm getting:

Linking: .build/whitefox_albertogg.elf                                                              [ERRORS]
 | 
 | /bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/libg.a(lib_a-sbrkr.o): In function `_sbrk_r':
 | sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'
 | collect2: error: ld returned 1 exit status
 | 
tmk_core/rules.mk:298: recipe for target '.build/whitefox_albertogg.elf' failed
make[1]: *** [.build/whitefox_albertogg.elf] Error 1

System Information

  • Keyboard:
    • Revision (if applicable): WhiteFox, vanilla layout revision v1.1
  • Operating system: macOS
  • AVR GCC version: whatever is in the latest Docker qmkfm/base_container
  • ARM GCC version: same as above
  • QMK Firmware version: 0.7.129
  • Any keyboard related software installed?
    • AutoHotKey
    • Karabiner
    • Other:
@zvecr
Copy link
Member

zvecr commented Jan 31, 2020

The cause (and a workaround) can be seen within #7059.

@albertogg
Copy link
Contributor Author

Thanks @zvecr, I guess we can close this as it seems to be an issue not easily solvable. Quick question is this workaround safe to use?

@zvecr
Copy link
Member

zvecr commented Jan 31, 2020

"safe" depends on a few things, we don't malloc much so there are not a lot of scenarios where we would be leaking. That said, the workaround hasn't had much exposure so YMMV.

@albertogg
Copy link
Contributor Author

Thanks! @zvecr

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants