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

Filesystem Hierarchy Standard and build.zig's linkSystemLibrary #2575

Closed
ghost opened this issue May 28, 2019 · 3 comments
Closed

Filesystem Hierarchy Standard and build.zig's linkSystemLibrary #2575

ghost opened this issue May 28, 2019 · 3 comments
Labels
enhancement Solving this issue will likely involve adding new logic or components to the codebase. zig build system
Milestone

Comments

@ghost
Copy link

ghost commented May 28, 2019

build.zig's linkSystemLibrary function does not look into all the necessary directories at the moment.

In section 4.8 of the Filesystem Hierarchy Standard it states:

/usr/lib<qual> performs the same role as /usr/lib for an alternate binary format, except that the
symbolic links /usr/lib/sendmail and /usr/lib/X11 are not required.

In section 3.1 it states:

There may be one or more variants of the /lib directory on systems which support more than one binary format requiring separate libraries.

This is commonly used for 64-bit or 32-bit support on systems which support multiple binary formats, but require libraries of the same name. In this case, /lib32 and /lib64 might be the library directories, and /lib a symlink to one of them.

I think we can ignore /lib* but not /usr/lib*. In Fedora's case there's /usr/lib and /usr/lib64 which are separate directories. There's no /usr/lib32. linkSystemLibrary does not look into /usr/lib64 at the moment.

@ghost
Copy link
Author

ghost commented May 28, 2019

I didn't see the TODO in build.zig. Here's my result for "ld --verbose | grep SEARCH_DIR":

SEARCH_DIR("=/usr/x86_64-redhat-linux/lib64"); SEARCH_DIR("=/usr/lib64"); SEARCH_DIR("=/usr/local/lib64"); SEARCH_DIR("=/lib64"); SEARCH_DIR("=/usr/x86_64-redhat-linux/lib"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib");

I assume that /usr/lib64 is the most important one to get, but I might be wrong.

Edit: For now I just call builder.addNativeSystemLibPath myself which is a fine but temporary solution.

@andrewrk andrewrk added this to the 0.5.0 milestone May 28, 2019
@andrewrk andrewrk added the enhancement Solving this issue will likely involve adding new logic or components to the codebase. label May 28, 2019
@andrewrk
Copy link
Member

andrewrk commented May 28, 2019

Related: #2041

@tiehuis suggested that this functionality should also exist in the compiler itself and I agree. Here's my plan of action:

  • Redefine/clarify --library [arg] option to mean "link against the system library named [arg]". Maybe this redefinition/clarification comes with a corresponding CLI update. (Maybe -lfoo/-l foo to match c compilers).
  • Move the library searching logic from zig build into the self-hosted compiler.
  • Update the library searching logic with the improvements noted in this issue.
  • Expose the self-hosted library searching logic to stage1 via libuserland.a (even stage1 now is a hybrid of zig/c++ code). This works because building libuserland.a does not need to search for system libraries.
  • Update link.cpp to never pass names to the linker; instead opting to pass absolute paths. Zig wants to be able to know exactly what files are being linked. This could be important for some planned features, and could prevent issues such as the one on Windows where the wrong .lib files are picked up.

@andrewrk andrewrk modified the milestones: 0.5.0, 0.6.0 Aug 28, 2019
@andrewrk
Copy link
Member

duplicate of #2041

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Solving this issue will likely involve adding new logic or components to the codebase. zig build system
Projects
None yet
Development

No branches or pull requests

1 participant