# Using R and JuliaCall is not reliable without assigning R environment variables before starting R

**URL:** <https://discourse.julialang.org/t/using-r-and-juliacall-is-not-reliable-without-assigning-r-environment-variables-before-starting-r/133445>\
**Category:** General Usage\
**Tags:** juliacall\
**Created:** [October 26, 2025, 9:55pm UTC](https://discourse.julialang.org/t/using-r-and-juliacall-is-not-reliable-without-assigning-r-environment-variables-before-starting-r/133445 "2025-10-26T21:55:21Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![RobertDorazio](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/robertdorazio/32/218538_2.png) [@RobertDorazio](https://discourse.julialang.org/u/RobertDorazio)\
**Post date:** [October 26, 2025, 9:55pm UTC](https://discourse.julialang.org/t/using-r-and-juliacall-is-not-reliable-without-assigning-r-environment-variables-before-starting-r/133445/1 "2025-10-26T21:55:21Z")

</div>

Suppose the file “sourceCode.R” contains an R script that calls a Julia function using julia\_call(), which is defined in the R package JuliaCall.

If R is started in a Linux terminal using the command “R”, then the R command “source(sourceCode.R)” produces a segmentation fault (core dumped).

In contrast, if R is started in a Linux terminal using the following code:

R\_HOME=/usr/lib/R  
export R\_HOME  
R\_SHARE\_DIR=/usr/share/R/share  
export R\_SHARE\_DIR  
R\_INCLUDE\_DIR=/usr/share/R/include  
export R\_INCLUDE\_DIR  
R\_DOC\_DIR=/usr/share/R/doc  
export R\_DOC\_DIR  
exec /usr/lib/R/bin/exec/R

then the R command “source(sourceCode.R)” executes without errors.

Evidently, explicitly setting these R-related environment variables to their correct system paths BEFORE running R is needed to ensured that both R and any external libraries it calls (like JuliaCall) have the precise, necessary information to locate all R components.

This correct path information allows the underlying inter-language connection to be established cleanly, preventing the memory access error.

Unfortunately, running R from the Linux terminal is not nearly as convenient as running R within Emacs (or another editor), where R code can be edited and run more easily. Does anyone have an alternative solution to this problem?

FYI: I am using Julia 1.12.1 and Ubuntu 24.04.

---

<div class="post-metadata">

**Author:** ![technocrat](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/technocrat/32/220947_2.png) [@technocrat](https://discourse.julialang.org/u/technocrat)\
**Post date:** [October 26, 2025, 11:04pm UTC](https://discourse.julialang.org/t/using-r-and-juliacall-is-not-reliable-without-assigning-r-environment-variables-before-starting-r/133445/2 "2025-10-26T23:04:59Z")

</div>

Am I missing something? Why not put those in your .bashrc/.zshrc?

---

<div class="post-metadata">

**Author:** ![RobertDorazio](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/robertdorazio/32/218538_2.png) [@RobertDorazio](https://discourse.julialang.org/u/RobertDorazio)\
**Post date:** [October 26, 2025, 11:20pm UTC](https://discourse.julialang.org/t/using-r-and-juliacall-is-not-reliable-without-assigning-r-environment-variables-before-starting-r/133445/3 "2025-10-26T23:20:15Z")

</div>

I tried executing all lines except “exec /usr/lib/R/bin/exec/R” and then executing “R”. Doing so results in a segmentation fault.

---

<div class="post-metadata">

**Author:** ![technocrat](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/technocrat/32/220947_2.png) [@technocrat](https://discourse.julialang.org/u/technocrat)\
**Post date:** [October 27, 2025, 1:01am UTC](https://discourse.julialang.org/t/using-r-and-juliacall-is-not-reliable-without-assigning-r-environment-variables-before-starting-r/133445/4 "2025-10-27T01:01:17Z")

</div>

I get a segment fault, also, on substantially the same setup. This, however, works

```julia-auto
# miscellaneous.jl
function agm(a, b; tol = 1.0e-15)
    a0 = a; b0 = b
    while abs(b0-a0) >= tol
        a0, b0 = (a0 + b0)/2.0, sqrt(a0 * b0)
    end
    return (a0 + b0) / 2.0
end

```

```R
library(JuliaCall)
julia_source("miscellaneous.jl")
julia_exists("agm")

```

```returns
TRUE

```

---

<div class="post-metadata">

**Author:** ![RobertDorazio](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/robertdorazio/32/218538_2.png) [@RobertDorazio](https://discourse.julialang.org/u/RobertDorazio)\
**Post date:** [October 27, 2025, 1:31am UTC](https://discourse.julialang.org/t/using-r-and-juliacall-is-not-reliable-without-assigning-r-environment-variables-before-starting-r/133445/5 "2025-10-27T01:31:48Z")

</div>

My original post should have stated:  
If R is started in a Linux terminal using the command “R”, then the R command “source(sourceCode.R)” may produce a segmentation fault (core dumped).

That is, a segmentation fault is not produced for every R source code. But occurrence of a segmentation fault is certainly not uncommon.

---

<div class="post-metadata">

**Author:** ![oheil](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oheil/32/220745_2.png) [@oheil](https://discourse.julialang.org/u/oheil)\
**Post date:** [October 27, 2025, 9:50am UTC](https://discourse.julialang.org/t/using-r-and-juliacall-is-not-reliable-without-assigning-r-environment-variables-before-starting-r/133445/6 "2025-10-27T09:50:43Z")

</div>

> [@RobertDorazio](#):
>
> exec /usr/lib/R/bin/exec/R

This line is a bit uncommon for me. Why not just

```julia-auto
/usr/lib/R/bin/exec/R

```

why the `exec`?  
Bash man-page tells:

```julia-auto
       exec [-cl] [-a name] [command [arguments]]
              If command is specified, it replaces the shell. No new process is created. The arguments become the arguments to command. If the -l option is supplied, the shell
              places a dash at the beginning of the zeroth argument passed to command. This is what login(1) does. The -c option causes command to be executed with an empty envi-
              ronment. If -a is supplied, the shell passes name as the zeroth argument to the executed command. If command cannot be executed for some reason, a non-interactive
              shell exits, unless the execfail shell option is enabled. In that case, it returns failure. An interactive shell returns failure if the file cannot be executed. A
              subshell exits unconditionally if exec fails. If command is not specified, any redirections take effect in the current shell, and the return status is 0. If there
              is a redirection error, the return status is 1.

```

Replacing the shell is probably something special, which may have some use cases. I never had to use it, that’s why I stumbled over it. So, perhaps, there is not a problem at all when you just run R with

```julia-auto
/usr/lib/R/bin/exec/R

```

I didn’t do any experiments, just a guess into nothing. You may try if you like.

---

<div class="post-metadata">

**Author:** ![RobertDorazio](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/robertdorazio/32/218538_2.png) [@RobertDorazio](https://discourse.julialang.org/u/RobertDorazio)\
**Post date:** [October 27, 2025, 4:36pm UTC](https://discourse.julialang.org/t/using-r-and-juliacall-is-not-reliable-without-assigning-r-environment-variables-before-starting-r/133445/7 "2025-10-27T16:36:22Z")

</div>

This solution was suggested at [https://github.com/JuliaInterop/JuliaCall/issues/238](https://github.com/JuliaInterop/JuliaCall/issues/238)

The idea is to assign the R environment variables and to launch R using one shell script.

However, this is no longer needed because the problems with the JuliaCall package have been resolved in a VERY RECENT update of the package, which can be downloaded from [https://github.com/JuliaInterop/JuliaCall](https://github.com/JuliaInterop/JuliaCall)

Robert