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

add _IO_stdin_used to julia.expmap #11422

Merged
merged 1 commit into from
May 25, 2015
Merged

add _IO_stdin_used to julia.expmap #11422

merged 1 commit into from
May 25, 2015

Conversation

tkelman
Copy link
Contributor

@tkelman tkelman commented May 24, 2015

fixes #10982
cc @garrison

@garrison
Copy link
Member

LGTM!

I wish I had more understanding of why this is necessary, but that is another matter. In particular, I'm wondering if it's typical/expected to use a "version script" with a binary (i.e. julia), or whether they are really only meant to be used with libraries (e.g. libjulia). In other words, are there any other symbols we really ought to be exporting? The difference between using julia.expmap on julia itself and not using it (but still using it for libjulia) is fairly minimal:

64   0: 0804cbd0     0 NOTYPE  GLOBAL DEFAULT  24 _edata
66   0: 0804c9c0     0 NOTYPE  GLOBAL DEFAULT  24 __data_start
67   0: 0804cbe4     0 NOTYPE  GLOBAL DEFAULT  25 _end
68   0: 08049870  2637 FUNC    GLOBAL DEFAULT  13 parse_opts
69   1: 0804c9c0     0 NOTYPE  WEAK   DEFAULT  24 data_start
70   1: 0804a384     4 OBJECT  GLOBAL DEFAULT  15 _IO_stdin_used
71   1: 0804a380     4 OBJECT  GLOBAL DEFAULT  15 _fp_hw
72   1: 08049100   134 FUNC    GLOBAL DEFAULT  13 main
73   1: 08049186     0 FUNC    GLOBAL DEFAULT  13 _start
74   1: 08048e18     0 FUNC    GLOBAL DEFAULT  11 _init
75   1: 0804cbd0     0 NOTYPE  GLOBAL DEFAULT  25 __bss_start
76   1: 0804a2f0    97 FUNC    GLOBAL DEFAULT  13 __libc_csu_init
77   2: 0804a364     0 FUNC    GLOBAL DEFAULT  14 _fini
78   2: 0804a360     2 FUNC    GLOBAL DEFAULT  13 __libc_csu_fini

So an alternative patch would be to use julia.expmap on libjulia but not julia. It's unclear to me which approach is more solid.

@garrison
Copy link
Member

cc @Keno

@tkelman
Copy link
Contributor Author

tkelman commented May 24, 2015

Yeah, I don't know either, but I figured it was worth sending through the CI at least.

@Keno
Copy link
Member

Keno commented May 24, 2015

From what I understand, one part of glibc uses the presence of this symbol to decide which version another part of it is and executes code conditional based one that. The version script hides the symbol and the version mismatch causes bad code to run. I think it would be fine to only use julia.exmap for libjulia and not for the executable.

@tkelman
Copy link
Contributor Author

tkelman commented May 25, 2015

The link command for the julia executable is
@$(call PRINT_LINK, $(CXXLD) $(CXXFLAGS) $(CXXLDFLAGS) $(LINK_FLAGS) $(SHIPFLAGS) $^ -o $@ -L$(build_private_libdir) -L$(build_libdir) -L$(build_shlibdir) -ljulia $(JLDFLAGS) $(CXXLDFLAGS))

So we'd have to fiddle with some of these flag variables to split them out and differentiate between libjulia and the executable. Let's just merge this since it's easier, and see if it hurts anything.

tkelman added a commit that referenced this pull request May 25, 2015
add _IO_stdin_used to julia.expmap
@tkelman tkelman merged commit 32f5a51 into master May 25, 2015
@tkelman tkelman deleted the tk/fix10982 branch May 25, 2015 06:56
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.

Invalid free() on exit (32-bit build under valgrind)
3 participants