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

Implement _NSGetEnviron() #1189

Closed
wants to merge 1 commit into from

Conversation

arlolra
Copy link
Contributor

@arlolra arlolra commented May 18, 2013

Configure detects the presence of _NSGetEnviron() on OS X but fails during make. Harmless to include it? Or just my problem?

@kripken
Copy link
Member

kripken commented May 21, 2013

Configure for what project?

@arlolra
Copy link
Contributor Author

arlolra commented May 21, 2013

Oh, the project I'm trying to build. Not emscripten itself.

@kripken
Copy link
Member

kripken commented May 21, 2013

Which project is it, out of curiosity? And what is NSGetEnviron?

@arlolra
Copy link
Contributor Author

arlolra commented May 21, 2013

tor

_NSGetEnviron() is used to get direct access to environ on OS X

@kripken
Copy link
Member

kripken commented May 21, 2013

And what header is it defined in? If configure checks for it, it must be in some system header of ours? Otherwise what is configure looking for?

@arlolra
Copy link
Contributor Author

arlolra commented May 21, 2013

It's defined in crt_externs.h on my system but nowhere in emscripten, hence the pull.

The configure file check is generated with automake's,

AC_CHECK_FUNCS(
    _NSGetEnviron \
    ...
)

I guess that bypasses whatever emconfigure does to ensure checks are against emscripten's system.

@kripken
Copy link
Member

kripken commented May 21, 2013

That header file is not part of emscripten though. I guess it's a system header on your machine?

@kripken
Copy link
Member

kripken commented May 21, 2013

We can't implement stuff in our library files that is specific to some system. In principle, configure should not be looking in your system headers, just the portable emscripten ones.

@arlolra
Copy link
Contributor Author

arlolra commented May 22, 2013

Indeed, it's a system header on my machine and, unfortunately, in practice, configure is looking at it.

I guess a better patch would be to figure why that is and try to prevent it. Thanks for the help.

@kripken
Copy link
Member

kripken commented May 22, 2013

I think the right solution is to modify that configure to be more friendly to cross-compilers (like emscripten), and not look at hardcoded paths to system headers. I am not sure there is something more general we can do.

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.

2 participants