_jl_base_ctx not exported in libjulia.dynlib

[waTeim]

I suspect that the new variable jl_base_ctx that is part of addressing #8551 is not being exported, which is preventing successful link by embedding programs (ok mine) on OS/X

dlopen(/Users/travis/build/waTeim/node-julia/build/Release/nj.node, 1): Symbol not found: _jl_base_ctx

When examined using nm, it looks like it's a static -- maybe that's the default clang compile mode?

bizarro% nm -pa libjulia.dylib | grep jl_base_ctx
0000000000000000 - 00 0000  GSYM _jl_base_ctx
0000000000d06920 s _jl_base_ctx

The decl in julia.h

extern jl_jmp_buf jl_base_ctx;

should probably instead be (guessing)

extern DLLEXPORT jl_jmp_buf jl_base_ctx;

[ViralBShah]

Cc: @vtjnash

Looks like a simple case of adding DLLEXPORT.

[vtjnash]

agreed. should be added at both decl sites (in julia.h and task.c)

[waTeim]

Thanks guys, although I found it in task.c -- does it need to be moved? I modified locally last night and that fixed it my problem I would have sent pull request too, but I still have git-drama going on in my repo (specifically submodule drama).

[tkelman]

@waTeim 90% of the time with submodules all you need to do is git submodule update to make false-alarm diffs go away. Just don't try adding or committing submodule diffs that appear during the regular course of pulling julia master unless you know that's exactly what you're trying to do.

[waTeim]

@tkelman Oh man, thanks for the continued help; the problem occurs during rebase; I tried submodule update. But then this

bizarro% git rebase upstream/master
First, rewinding head to replay your work on top of it...
Applying: Synchronized with upstream
Using index info to reconstruct a base tree...
M   deps/libuv
M   deps/openlibm
M   deps/openspecfun
Falling back to patching base and 3-way merge...
warning: Failed to merge submodule deps/openspecfun (commits don't follow merge-base)
warning: Failed to merge submodule deps/openlibm (commits don't follow merge-base)

I just want to get out of this rebase hell, I feel nuking my whole repo and starting from scratch would be better except for the one outstanding pull request.

[tkelman]

Synchronized with upstream sounds like it's a merge commit. Try rebase -i and dropping that commit.

[waTeim]

There are a bunch like that, but this is what I did

git pull upstream master
git rebase -i upstream/master

And then I dropped all commits except the last one

And that left me ok with 1 exception -- all other submodules are the correct commit hash (same as julia main)

bizarro% git submodule status
...
 5599b8cdbb369e1ab17d48ed7d9d60d5ee279a26 deps/libuv (v0.11.22-142-g5599b8c)
...

[tkelman]

Generally don't do pull if you're planning on doing a rebase right after. Just do fetch then rebase.

You want to drop merge commits when you rebase, only leave in the manual commits you've made. The "last one" will probably be a merge commit if you do pull, unless your branch is perfectly clean and the pull is a fast-forward.

If now you're in a state where the only commit touches both the submodule and other files you want to keep, one way would be adding a new commit that just undoes the submodule change, and squashing that together with the first commit. That should cancel out and remove the submodule change from your branch.

[waTeim]

Well after multiple tries, I think might have been ok, but now it's hopelessly messed up. I just wanted to overwrite whatever I did with what's in the main repo and start over.

Is there a command that does: Diff origin and upstream and whenever there is a difference, take upstream and afterwards erase all previous history? I though rebase in effect would do that. But I was offered up so many merge conflicts I eventually took the wrong one (or 2 dozen), and now it feels impossible to get back.

[tkelman]

git checkout upstream/master
git push waTeim +master

replace waTeim with whatever you have the remote for your fork called

[tkelman]

that just overwrites your master with a copy of upstream which I think is what you're asking for

[waTeim]

That's what I want but that didn't work, git thinks my repo it's 273 commits ahead, probably because I tried to solve things with rebase

At this point I think I should really save my edits for #8880 nuke my repo, re-fork and re-create. What would that do to that pull request?

[tkelman]

Good question. I think what might happen is it would briefly say waTeim wants to merge 1 commit into JuliaLang:master from unknown repository. Worst case we close that PR and make a new one. You can save it as a patch file from https://github.com/JuliaLang/julia/pull/8880.patch before you delete your fork.

[vtjnash]

To get back to the date you want, you can do
git reset --hard

To find that state, you can look in the history:
git reflog

As an alternative to rebase -i, you can do each commit manually:
git cherry-pick -n

Submodules are versioned like regular files, so the usual commands like "git checkout deps/libuv" works as it would with a file (note no trailing slash)

[waTeim]

I did try it and that would have worked except for I probably need to do git reset --hard HEAD~xxx
where xxx is somewhere between 200 and 300, and I'm not sure which.

Back to this fix. It appears the problem is solved on OS/X but occurs on Linux -- maybe the Linux nightlies lag a little behind OS/X?

[vtjnash]

you can also give it the name of a branch: git reset --hard origin/master (and if you don't like the result, you can use the reflog to get back). just a fair warning: --hard will reset your working directory and lose any changes you had locally. do a git stash or git commit -m "WIP" (and take note of the resulting sha1 hash) first, if you want to preserve that code

[waTeim]

Well that was easy while on origin branch = master

git reset --hard upstream/master
git push  -f