-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
Update ccalltest #13077
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
Update ccalltest #13077
Conversation
Ah, it's definitely good to have you around! |
src/Makefile
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably will need to make corresponding removals in test/Makefile
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, weird, I somehow didn't get those changes included. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should also be cleaned
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think the ccalltest
binary has reached the limit of its usefulness. at this point, it's pretty much just a test of whether you have a compiler (and a pretty poor test of that too). I recommend just removing this Makefile rule and the corresponding function main
from ccalltest.c
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was wondering what it was used for, but didn't want to muck with things
beyond my knowledge. Will do.
-E
On Sat, Sep 12, 2015 at 5:24 PM, Jameson Nash notifications@github.com
wrote:
In src/Makefile
#13077 (comment):@@ -82,6 +82,14 @@
$(BUILDDIR)/%.o: %.cpp $ (HEADERS)$(shell which $ (LLVM_CONFIG)) | $(BUILDDIR)
$(BUILDDIR)/%.dbg.obj: %.cpp $ (HEADERS)$(shell which $ (LLVM_CONFIG)) | $(BUILDDIR)
@$(call PRINT_CC,$(CXX) $ (call exec,$(LLVM_CONFIG) --cxxflags)$(CPPFLAGS) $ (CXXFLAGS)$(DEBUGFLAGS) -c $ < -o $@)+libccalltest:
$(build_shlibdir)/libccalltest.$ (SHLIB_EXT)
+$(build_shlibdir)/libccalltest.$(SHLIB_EXT): ccalltest.c
- @$(call PRINT_CC,
$(CC) $ (CFLAGS)$(DEBUGFLAGS) -O3 $ <$(fPIC) -shared -o $ @$(LDFLAGS) -DCC="$ (CC)")
+$(BUILDDIR)/ccalltest: ccalltest.c$(BUILDDIR)/libccalltest.$ (SHLIB_EXT)- @$(call PRINT_CC,
$(CC) $ (CFLAGS)$(DEBUGFLAGS) -O3 $ < -o$@ $ (LDFLAGS) -DCC="$(CC)")i think the ccalltest binary has reached the limit of its usefulness. at
this point, it's pretty much just a test of whether you have a compiler
(and a pretty poor test of that too). I recommend just removing this
Makefile rule and the corresponding function main from ccalltest.c.—
Reply to this email directly or view it on GitHub
https://github.com/JuliaLang/julia/pull/13077/files#r39342989.
Ah, I was originally putting it in a place that didn't require cleaning (in |
mind squashing a bit? |
b7e6297
to
a2d4016
Compare
Squished and squashed. |
test/Makefile
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm not exactly sure what gmake will do with this line (all:
), probably best just to delete it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I missed that all
gets expanded out of $(TESTS)
.
359cd46
to
9afed54
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for other reviewers: this change shouldn't be necessary, since dllexport is the default for Mac, Linux, and Mingw64 compilers. However, it could perhaps be somewhat useful if dealing with MSVC in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
msvc can't really build this file as it stands right now since it doesn't support C-style complex
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think it should only really matter if msvc tried to link against the resulting file (even if mingw compiled it), which is even less likely however. and none of that matters unless you are also going to create the lib.a
file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dll visibility matters for ccall - the default with mingw is only to export everything if there are no export attributes present. If you have a single dllexport that is explicitly specified, then only that function gets exported (unless you link with -Wl,--export-all-symbols
). So it either needs to be nowhere or on everything you want to use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, the reason I added these DLLEXPORT
things is because on Linux, with GCC, the symbols weren't accessible. nm
showed them as 't'
instead of 'T'
which apparently means "local", but I'm honestly a little fuzzy as to what exactly that means. It's possible that what Tony just said is the culprit; something else was getting exported which caused everything else to be non-visible, but at least things are more explicit this way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CFLAGS has a special meaning inside of src/Makefile due to an override at the top
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point; I've removed CFLAGS
and replaced it with CPPFLAGS
now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it should still have CFLAGS as well, to accommodate where-ever the user's environment is injecting the flags
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I thought that since we're setting CFLAGS
to JCFLAGS
, we didn't want to pass them. I'll reinstate CFLAGS
alongside CPPFLAGS
then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it contains a lot of unnecessary cruft, but it might contain user flags
9afed54
to
853bfbd
Compare
This okay to merge? |
853bfbd
to
9cc67dc
Compare
I think it is now ready to merge, if @vtjnash agrees then we're ready to go. |
backported in #13107 |
Move ccalltest.c to src, install into private_libdir, ensure symbols are public.
Addresses #12779