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

Provide compiler specs with default esp8266-specific libraries/map file #209

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

jcmvbkbc
Copy link
Contributor

This series fixes issue #199 and also fixes examples/blinky build (which now requires linking with libc b/o liblwip.a(espconn_buf.o)).

The specs file gives the list of default libraries, linker script (if
one is not specified in the command line) and empty set of start and end
files.

-T command line option may be used to override the default linker script.
-nodefaultlibs or -nostdlib switches may be used to empty spec-supplied
set of default libraries.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Now that gcc links with necessary libraries and linker script by default
and does not try to use start and end files drop these options.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
@pfalcon
Copy link
Owner

pfalcon commented Oct 20, 2016

I'm not sure I want to go as far as this. This patch leaves an impression that vendor libraries are integral part of open-source toolchain. But they aren't, they are proprietary, foreign constructs. Users should be well aware of that. As a particular example, with advent of liblwip_open.a, vendor's liblwip.a is no longer supported by esp-open-sdk. Like, I'm not going to forcibly remove it, and even give up on a plan to rename it to liblwip_proprietary.a, and current liblwip_open.a - to liblwip.a. But users are discouraged from using vendor's liblwip.a, and any bugs regarding it are non-bugs from esp-open-sdk's perspective.

@jcmvbkbc
Copy link
Contributor Author

jcmvbkbc commented Oct 20, 2016

That's OK, I'll leave it here as a demonstration of what can be done.
BTW, using this technique we can introduce new gcc options right in the spec file, e.g. we can introduce -mfree-libs for linking with the free library versions and -mespressif-libs for linking with vendor libraries.

We can also limit this series to at least not trying to link with crt1-sim.o, _vectors.o, -lsim and -lhandlers-sim by default.

@dev-zzo
Copy link

dev-zzo commented Dec 12, 2017

At the very least, please remove the confusing and irrelevant things from LIB_SPEC. Should be as simple as patching /src/gcc-4.8.5/gcc/config/xtensa/elf.h: to state #define LIB_SPEC "-lc -lhal" -- please let me know if you'd like a pull request for the relevant changes.

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

Successfully merging this pull request may close these issues.

None yet

3 participants