Silly: What is the difference between --sysroot and --isysroot?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Silly: What is the difference between --sysroot and --isysroot?

David Chisnall via cfe-dev
Hi!
 
We've just tried to setup "DEFAULT_SYSROOT" in cmake while compiling clang for Darwin and bumped into several test failures.
 
Most indicating is a "sysroot.c" failure:
 
It seems that one of subtests passes "--isysroot" into the driver call, and expects that driver will pass the same value into "-syslibroot" for linker. But as long as default sysroot has been specified, it overwhelms "--isysroot" impact on linker and thus bypass another string into "-syslibroot".
 
Another question. Why such tests relies on a logic, that if you pass cc1 related parameter into the driver it should bypass it into the linker. Obviously it is a very fragile assumption, or I miss something and there is special role for "isysroot" while passing to driver?
 
Thanks!
 
Also here is a check-clang log with full list of failures:
 
 
And this is a CI job which fails:
 
 
-Stepan Dyatkovskiy

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Silly: What is the difference between --sysroot and --isysroot?

David Chisnall via cfe-dev
Darwin has really weird behavior for "-isysroot", I think for some historical reason, I'm not really sure. I believe it was added to Clang to be compatible with the behavior of Darwin GCC. But I don't know why Darwin GCC did this.

Usually, -isysroot is the sysroot used only for looking for header files, and if -isysroot isn't specified, then the value specified by --sysroot is used for header searching also. But, on darwin, -isysroot almost acts as an alias for --sysroot, in that it applies to libraries as well. Unless --sysroot is specified, in which case that takes precedence for libraries. Darwin also has a bunch of weird magic for inferring the default "-target" argument, based on the path name passed to -isysroot.

So, this is what you're seeing: the test is asserting that running "clang -isysroot FOO" will look in the directory FOO for libraries, on Darwin. But because you've built it with a default sysroot value, that no longer occurs -- now it's going to look for libraries in your default sysroot, instead. So, this does indicate an actual problem, but it may well be that none of your users rely on this weirdness, and therefore maybe it's fine that this test is broken.

It'd be really nice if all of that weirdness could be removed from the Darwin code, and sysroot and isysroot would just act as they do everywhere else. But I have no idea if that'd break things.

As for the other failures: at least some of those (if not all) seem to be harmless test fragility -- they are assuming sysroot is unset by default, which then implies that Clang will go looking next to its own directory for various bits and pieces. If you're configuring a clang distribution with a default sysroot, then that's probably reasonably expected that it not do that. These tests could probably be repaired by adding "--sysroot=" to the command line. (But, note: I haven't actually investigated them all.)

On Wed, Jul 1, 2020 at 12:52 PM [hidden email] via cfe-dev <[hidden email]> wrote:
Hi!
 
We've just tried to setup "DEFAULT_SYSROOT" in cmake while compiling clang for Darwin and bumped into several test failures.
 
Most indicating is a "sysroot.c" failure:
 
It seems that one of subtests passes "--isysroot" into the driver call, and expects that driver will pass the same value into "-syslibroot" for linker. But as long as default sysroot has been specified, it overwhelms "--isysroot" impact on linker and thus bypass another string into "-syslibroot".
 
Another question. Why such tests relies on a logic, that if you pass cc1 related parameter into the driver it should bypass it into the linker. Obviously it is a very fragile assumption, or I miss something and there is special role for "isysroot" while passing to driver?
 
Thanks!
 
Also here is a check-clang log with full list of failures:
 
 
And this is a CI job which fails:
 
 
-Stepan Dyatkovskiy
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Silly: What is the difference between --sysroot and --isysroot?

David Chisnall via cfe-dev
Thanks for explanation!
May be we then could fix DEFAULT_SYSROOT behaviour, or add an alternative. Which would act as follows.
In clang cc1 in case of absent isysroot we use  DEFAULT_SYSROOT. Same with linker.
Not sure though whether it will break existinf buildbots or not.

-Stepan

02.07.2020, 02:07, "James Y Knight" <[hidden email]>:
Darwin has really weird behavior for "-isysroot", I think for some historical reason, I'm not really sure. I believe it was added to Clang to be compatible with the behavior of Darwin GCC. But I don't know why Darwin GCC did this.

Usually, -isysroot is the sysroot used only for looking for header files, and if -isysroot isn't specified, then the value specified by --sysroot is used for header searching also. But, on darwin, -isysroot almost acts as an alias for --sysroot, in that it applies to libraries as well. Unless --sysroot is specified, in which case that takes precedence for libraries. Darwin also has a bunch of weird magic for inferring the default "-target" argument, based on the path name passed to -isysroot.

So, this is what you're seeing: the test is asserting that running "clang -isysroot FOO" will look in the directory FOO for libraries, on Darwin. But because you've built it with a default sysroot value, that no longer occurs -- now it's going to look for libraries in your default sysroot, instead. So, this does indicate an actual problem, but it may well be that none of your users rely on this weirdness, and therefore maybe it's fine that this test is broken.

It'd be really nice if all of that weirdness could be removed from the Darwin code, and sysroot and isysroot would just act as they do everywhere else. But I have no idea if that'd break things.

As for the other failures: at least some of those (if not all) seem to be harmless test fragility -- they are assuming sysroot is unset by default, which then implies that Clang will go looking next to its own directory for various bits and pieces. If you're configuring a clang distribution with a default sysroot, then that's probably reasonably expected that it not do that. These tests could probably be repaired by adding "--sysroot=" to the command line. (But, note: I haven't actually investigated them all.)

On Wed, Jul 1, 2020 at 12:52 PM [hidden email] via cfe-dev <[hidden email]> wrote:
Hi!
 
We've just tried to setup "DEFAULT_SYSROOT" in cmake while compiling clang for Darwin and bumped into several test failures.
 
Most indicating is a "sysroot.c" failure:
 
It seems that one of subtests passes "--isysroot" into the driver call, and expects that driver will pass the same value into "-syslibroot" for linker. But as long as default sysroot has been specified, it overwhelms "--isysroot" impact on linker and thus bypass another string into "-syslibroot".
 
Another question. Why such tests relies on a logic, that if you pass cc1 related parameter into the driver it should bypass it into the linker. Obviously it is a very fragile assumption, or I miss something and there is special role for "isysroot" while passing to driver?
 
Thanks!
 
Also here is a check-clang log with full list of failures:
 
 
And this is a CI job which fails:
 
 
-Stepan Dyatkovskiy
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev




_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev