# Strange include path in unix.h in "Generic Linux Binaries for x86"

**URL:** <https://discourse.julialang.org/t/strange-include-path-in-unix-h-in-generic-linux-binaries-for-x86/21511>\
**Category:** Internals & Design\
**Tags:** package\
**Created:** [March 5, 2019, 9:05pm UTC](https://discourse.julialang.org/t/strange-include-path-in-unix-h-in-generic-linux-binaries-for-x86/21511 "2019-03-05T21:05:03Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![mmmm1998](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mmmm1998/32/7799_2.png) [@mmmm1998](https://discourse.julialang.org/u/mmmm1998)\
**Post date:** [March 5, 2019, 9:05pm UTC](https://discourse.julialang.org/t/strange-include-path-in-unix-h-in-generic-linux-binaries-for-x86/21511/1 "2019-03-05T21:05:03Z")

</div>

I have a question about `include/julia/uv/unix.h:45` (obvicious, this is relative path from the julia root directory). That this line  
`#include "uv/threadpool.h"`

First, isn’t this statement tried to include `include/julia/uv/threadpool.h`?  
But, in this case, why not just like that `#include "threadpool.h"`.

As I understand, with current include path, compiler look up in `include/julia/uv`and tryies to find `include/julia/uv/uv`, which not exists. And, after that, starts search in system include paths. And if `include/julia` exists in system include paths, we succesfully will found the `threadpool.h`. And if not, build will failed.

It’s not look good, or I miss something?

---

<div class="post-metadata">

**Author:** ![mmmm1998](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mmmm1998/32/7799_2.png) [@mmmm1998](https://discourse.julialang.org/u/mmmm1998)\
**Post date:** [March 5, 2019, 9:27pm UTC](https://discourse.julialang.org/t/strange-include-path-in-unix-h-in-generic-linux-binaries-for-x86/21511/2 "2019-03-05T21:27:08Z")

</div>

Also, there are a lot of embedded libuv in my system.  
For example, `/home/mmmm1998/.atom/.node-gyp/.node-gyp/iojs-1.3.13/deps/uv/include/uv-unix.h`  
This file similar to julia `unix.h`(similar structure), but the file include their `threadpool.h` like this:  
`#include "uv-threadpool.h"`

Also, some include statemant have this files (as I say, there are a lot of files, but I mention only files, used in fairly large projects):  
`/usr/local/include/node/uv-unix.h`  
`/usr/include/uv-unix.h`

---

<div class="post-metadata">

**Author:** ![jballanc](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jballanc/32/328_2.png) [@jballanc](https://discourse.julialang.org/u/jballanc)\
**Post date:** [March 7, 2019, 3:26am UTC](https://discourse.julialang.org/t/strange-include-path-in-unix-h-in-generic-linux-binaries-for-x86/21511/3 "2019-03-07T03:26:43Z")

</div>

I believe the source of your confusion is that using `#include` in C with quotes (") _can_ find the file to include on the local path but will _also_ fall back to searching the full include path. So, yes, `#include "uv/threadpool.h"` will _first_ try to find `include/julia/uv/uv/threadpool.h` but failing that, and assuming that `include/julia` is in the include path, it will then find and include the appropriate `include/julia/uv/threadpool.h`.

---

<div class="post-metadata">

**Author:** ![mmmm1998](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mmmm1998/32/7799_2.png) [@mmmm1998](https://discourse.julialang.org/u/mmmm1998)\
**Post date:** [March 10, 2019, 4:23pm UTC](https://discourse.julialang.org/t/strange-include-path-in-unix-h-in-generic-linux-binaries-for-x86/21511/4 "2019-03-10T16:23:54Z")

</div>

I understand, how this `#include` works. I don’t understand, why we don’t use `#include "threadpool.h"`.  
I use embedded julia, so this strange include path brings me some pain, forcing add `JULIA_ROOT/include/julia` to include directories, which not very comfortable solution.  
Maybe, i should create bug report about it…

---

<div class="post-metadata">

**Author:** ![olsoni](https://avatars.discourse-cdn.com/v4/letter/o/4af34b/32.png) [@olsoni](https://discourse.julialang.org/u/olsoni)\
**Post date:** [April 3, 2019, 11:16pm UTC](https://discourse.julialang.org/t/strange-include-path-in-unix-h-in-generic-linux-binaries-for-x86/21511/5 "2019-04-03T23:16:19Z")

</div>

Wanted to chime in and mention that the strange include path is giving us some pain as well. We need to link to the Julia uv library to use async C callbacks and the current structure of the includes within `uv.h` and the files within the `JULIA_ROOT/include/julia/uv` folder require you to add `JULIA_ROOT/include/julia` to your include paths. This can generate an ambiguity when specifically trying to include headers from the julia folders where it creates a default behavior of defaulting back to system libraries instead of generating a compiler error if the include path was not set up properly.

I would suggest modifying the files within `JULIA_ROOT/include/julia` to structure their own includes so that they only expect the `JULIA_ROOT/include/` to be in the include path. We haven’t forayed into the julia source code yet, but we’d be happy to push up a possible fix if there’s indication that we could get traction with it.

@mmmm1998 did you end up making a bug report in the github about this issue?

---

<div class="post-metadata">

**Author:** ![mmmm1998](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mmmm1998/32/7799_2.png) [@mmmm1998](https://discourse.julialang.org/u/mmmm1998)\
**Post date:** [April 4, 2019, 9:31am UTC](https://discourse.julialang.org/t/strange-include-path-in-unix-h-in-generic-linux-binaries-for-x86/21511/6 "2019-04-04T09:31:54Z")

</div>

No, i didn’t report this issue. But, as I see, that there are another people, which have this problem, so I have created the [bug report](https://github.com/JuliaLang/julia/issues/31609) today.