ACLiC compilation confuses compiled binaries with shared objects, breaking compilation in some cases #7366
Comments
|
i think there is a bug in how the aclic compilation command is built i see this compilation command for one of the RDF roottests: i.e. The last two arguments are bogus, SImilarly for the failure reported in the issue description: there are 2 weird extra arguments appended to the compiler invocation that end up causing obscure aclic compilation failures. |
|
At TSystem.cxx:3340, in returns where I'm pretty sure the last two argument shouldn't be present. |
|
In As |
|
Assigning to @vgvassilev as the problem seems to be that |
|
@eguiraud, thanks for the detailed analysis. Unfortunately this works as designed and I am not sure if we can fix that behavior in a way that is reasonable when running the tests while keeping it working for the rest. If the issue is just for the test suite, I'd propose slitting these tests into subfolders. |
|
@vgvassilev I am confused, why does |
That would mean the design is broken and needs to be reconsidered, possibly by re-introducing rootmap files. @pcanal FYI |
|
Also note that this is (or seems to be) a relatively recent problem, we only see it on Arch and Gentoo since a few months. |
Ah, if those are executables and not shared objects that’s indeed a bug that can be fixed. |
Is the |
|
|
|
Unfortunately I do not have access to such a system but if you can build with If that is the case then there might be a problem with the Elf representation (or ACLiC is missing some compiler/linker flag). |
|
The issue description links to a dockerfile that reproduces the problem |
|
The link seems broken for me. |
|
Sorry, gitlab makes projects private by default. Now fixed 😓 |
|
Hi @vgvassilev , could you suggest a workaround for this? It prevents me from running certain tests locally 😅 |
|
Sorry I can look at that soon. I am not really sure if that can be worked around. |
|
Some updates:
There is nothing wrong with the implementation per se. For some reason the system compiles the |
|
Possibly relevant (this or one of the related questions): https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object-instead-of-an-executable-binary-according-to Looks like the file magic being checked is not sufficient to distinguish between shared objs and executables (anymore)? |
|
Link right on target. Yeah, looks like pie is to enable address space randomization for executables. I am not sure if that’s important for ACLIC binaries. A fix/workaround of the problem would be to pass -fno-pie to the aclic command. |
Executables that are compiled with fPIE means they are compiled in a position independent manner and are almost indistinguishable from the shared objects. A reasonably reliable way to find if this was a `pie executable` is to check the `DF_1_PIE` in the dynamic section of ELF. Fixes root-project#7366 Patch by Alexander Penev (@alexander-penev)
Executables that are compiled with fPIE means they are compiled in a position
independent manner and are almost indistinguishable from the shared objects. A
reasonably reliable way to find if this was a `pie executable` is to check the
`DF_1_PIE` in the dynamic section of ELF.
The pseudo-code is:
```
if DT_FLAGS_1 dynamic section entry is present
if DF_1_PIE is set in DT_FLAGS_1:
print pie executable
else
print shared object
```
See https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object-instead-of-an-executable-binary-according-to/34522357#34522357
Fixes root-project#7366
Patch by Alexander Penev (@alexander-penev)
Executables that are compiled with fPIE means they are compiled in a position
independent manner and are almost indistinguishable from the shared objects. A
reasonably reliable way to find if this was a `pie executable` is to check the
`DF_1_PIE` in the dynamic section of ELF.
The pseudo-code is:
```
if DT_FLAGS_1 dynamic section entry is present
if DF_1_PIE is set in DT_FLAGS_1:
print pie executable
else
print shared object
```
See https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object-instead-of-an-executable-binary-according-to/34522357#34522357
Fixes root-project#7366
Patch by Alexander Penev (@alexander-penev)
|
@vgvassilev I have a similar setup (Arch Linux x86_64) and I can confirm that the patch fixes the problem. :-) |
|
Hi, works for me as well! It would be nice to have confirmation for Gentoo as well if and when @amadio has time to try this out, but the patch is a fix for the original issue. |
|
Sorry, I missed this before, please ping me in the issue description or add me as assignee next time to ensure I see it. Gentoo has |
|
Thank you Guilherme, afaik it's enough to run |
|
Ok, I will build the latest master and (maybe) report which tests are failing for me in a new issue then. Thanks! |
|
No dataframe tests fail for me, but a bunch of others do fail, so if this is in master, it should have fixed the problem in Gentoo. |
Executables that are compiled with fPIE means they are compiled in a position
independent manner and are almost indistinguishable from the shared objects. A
reasonably reliable way to find if this was a `pie executable` is to check the
`DF_1_PIE` in the dynamic section of ELF.
The pseudo-code is:
```
if DT_FLAGS_1 dynamic section entry is present
if DF_1_PIE is set in DT_FLAGS_1:
print pie executable
else
print shared object
```
See https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object-instead-of-an-executable-binary-according-to/34522357#34522357
Fixes root-project#7366
Patch by Alexander Penev (@alexander-penev)
Executables that are compiled with fPIE means they are compiled in a position
independent manner and are almost indistinguishable from the shared objects. A
reasonably reliable way to find if this was a `pie executable` is to check the
`DF_1_PIE` in the dynamic section of ELF.
The pseudo-code is:
```
if DT_FLAGS_1 dynamic section entry is present
if DF_1_PIE is set in DT_FLAGS_1:
print pie executable
else
print shared object
```
See https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object-instead-of-an-executable-binary-according-to/34522357#34522357
Fixes root-project#7366
Patch by Alexander Penev (@alexander-penev)
Executables that are compiled with fPIE means they are compiled in a position
independent manner and are almost indistinguishable from the shared objects. A
reasonably reliable way to find if this was a `pie executable` is to check the
`DF_1_PIE` in the dynamic section of ELF.
The pseudo-code is:
```
if DT_FLAGS_1 dynamic section entry is present
if DF_1_PIE is set in DT_FLAGS_1:
print pie executable
else
print shared object
```
See https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object-instead-of-an-executable-binary-according-to/34522357#34522357
Fixes root-project#7366
Patch by Alexander Penev (@alexander-penev)
Executables that are compiled with fPIE means they are compiled in a position
independent manner and are almost indistinguishable from the shared objects. A
reasonably reliable way to find if this was a `pie executable` is to check the
`DF_1_PIE` in the dynamic section of ELF.
The pseudo-code is:
```
if DT_FLAGS_1 dynamic section entry is present
if DF_1_PIE is set in DT_FLAGS_1:
print pie executable
else
print shared object
```
See https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object-instead-of-an-executable-binary-according-to/34522357#34522357
Fixes #7366
Patch by Alexander Penev (@alexander-penev)
Executables that are compiled with fPIE means they are compiled in a position
independent manner and are almost indistinguishable from the shared objects. A
reasonably reliable way to find if this was a `pie executable` is to check the
`DF_1_PIE` in the dynamic section of ELF.
The pseudo-code is:
```
if DT_FLAGS_1 dynamic section entry is present
if DF_1_PIE is set in DT_FLAGS_1:
print pie executable
else
print shared object
```
See https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object-instead-of-an-executable-binary-according-to/34522357#34522357
Fixes root-project/root#7366
Patch by Alexander Penev (@alexander-penev)
|
Hi @vgvassilev, It appears this issue is closed, but wasn't yet added to a project. Please add upcoming versions that will include the fix, or 'not applicable' otherwise. Sincerely, |
|
I guess this needs a backport to v6-26-00-patches? |
|
Reopening until it lands in 6.26 (also so we can set the project "fixed in 6.26") |
Executables that are compiled with fPIE means they are compiled in a position
independent manner and are almost indistinguishable from the shared objects. A
reasonably reliable way to find if this was a `pie executable` is to check the
`DF_1_PIE` in the dynamic section of ELF.
The pseudo-code is:
```
if DT_FLAGS_1 dynamic section entry is present
if DF_1_PIE is set in DT_FLAGS_1:
print pie executable
else
print shared object
```
See https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object-instead-of-an-executable-binary-according-to/34522357#34522357
Fixes root-project#7366
Patch by Alexander Penev (@alexander-penev)
|
A v6.26 backport is at #9676 |
Executables that are compiled with fPIE means they are compiled in a position
independent manner and are almost indistinguishable from the shared objects. A
reasonably reliable way to find if this was a `pie executable` is to check the
`DF_1_PIE` in the dynamic section of ELF.
The pseudo-code is:
```
if DT_FLAGS_1 dynamic section entry is present
if DF_1_PIE is set in DT_FLAGS_1:
print pie executable
else
print shared object
```
See https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object-instead-of-an-executable-binary-according-to/34522357#34522357
Fixes root-project#7366
Patch by Alexander Penev (@alexander-penev)
Executables that are compiled with fPIE means they are compiled in a position
independent manner and are almost indistinguishable from the shared objects. A
reasonably reliable way to find if this was a `pie executable` is to check the
`DF_1_PIE` in the dynamic section of ELF.
The pseudo-code is:
```
if DT_FLAGS_1 dynamic section entry is present
if DF_1_PIE is set in DT_FLAGS_1:
print pie executable
else
print shared object
```
See https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object-instead-of-an-executable-binary-according-to/34522357#34522357
Fixes #7366
Patch by Alexander Penev (@alexander-penev)
|
Hi @eguiraud, @vgvassilev, It appears this issue is closed, but wasn't yet added to a project. Please add upcoming versions that will include the fix, or 'not applicable' otherwise. Sincerely, |
Describe the bug
Building ROOT on Arch Linux and then running
ctest -R "(dataframe|datasource)" -- -j8results in several test failures.There are various possible failure modes -- the command above typically results in these kind of errors:
I did not manage to reproduce the problem outside of ctest and without running multiple tests concurrently -- it also seems that one of the tests "has" to be
roottest-root-dataframe-test_snapshot_manytasks.To Reproduce
The following repository provides a Dockerfile to reproduce the issue in a container https://gitlab.cern.ch/eguiraud/arch_aclic_bug .
Setup
ROOT master (but 6.22 also has issues) and arch linux.
I tried building from source (6.22 and master) as well as installing from the system repos -- failure modes are different but none can run all tests without problems.
Gentoo seems to also be affected.
The text was updated successfully, but these errors were encountered: