| Message ID | 20180407215822.2008-1-jamrial@gmail.com |
|---|---|
| State | Accepted |
| Commit | e7a2f1f8d8350a768ca88b61303449433962b52d |
| Headers | show |
On 4/7/2018 10:58 PM, James Almer wrote: > It appears strip -o creates new files without preserving permissions > from the source binary, resulting in non executable files. This sounds like something the OpenBSD people should be informed of, no? - Derek
On 4/9/2018 11:15 AM, Derek Buitenhuis wrote: > On 4/7/2018 10:58 PM, James Almer wrote: >> It appears strip -o creates new files without preserving permissions >> from the source binary, resulting in non executable files. > > This sounds like something the OpenBSD people should be informed of, no? > > - Derek Maybe they already know and it was fixed at some point, seeing the OpenBSD fate client we have has software from 2007 (gcc 4.2, and safe to assume equally outdated binutils).
On 4/9/2018 3:32 PM, James Almer wrote: > Maybe they already know and it was fixed at some point, seeing the > OpenBSD fate client we have has software from 2007 (gcc 4.2, and safe to > assume equally outdated binutils). OpenBSD doesn't update their toolchain AFAIK, but maintains their own forks, so probably still useful. - Derek
On 4/9/2018 11:35 AM, Derek Buitenhuis wrote: > On 4/9/2018 3:32 PM, James Almer wrote: >> Maybe they already know and it was fixed at some point, seeing the >> OpenBSD fate client we have has software from 2007 (gcc 4.2, and safe to >> assume equally outdated binutils). > > OpenBSD doesn't update their toolchain AFAIK, but maintains their own forks, > so probably still useful. > Looking at the packages shipped by OpenBSD in its latest version, they are using GCC 4.9, so I'm going to assume this was fixed long ago. Does anyone use a recent OpenBSD to confirm this, in any case? I may be able to add a GCC version check depending on that to this patch.
On 4/10/2018 8:54 PM, James Almer wrote: > On 4/9/2018 11:35 AM, Derek Buitenhuis wrote: >> On 4/9/2018 3:32 PM, James Almer wrote: >>> Maybe they already know and it was fixed at some point, seeing the >>> OpenBSD fate client we have has software from 2007 (gcc 4.2, and safe to >>> assume equally outdated binutils). >> >> OpenBSD doesn't update their toolchain AFAIK, but maintains their own forks, >> so probably still useful. >> > > Looking at the packages shipped by OpenBSD in its latest version, they > are using GCC 4.9, so I'm going to assume this was fixed long ago. > > Does anyone use a recent OpenBSD to confirm this, in any case? I may be > able to add a GCC version check depending on that to this patch. Pushed it as is in the meantime.
diff --git a/configure b/configure index 08d6fc5983..47eda6ca21 100755 --- a/configure +++ b/configure @@ -5045,6 +5045,7 @@ case $target_os in ;; openbsd|bitrig) disable symver + striptype="" SHFLAGS='-shared' SLIB_INSTALL_NAME='$(SLIBNAME).$(LIBMAJOR).$(LIBMINOR)' SLIB_INSTALL_LINKS=
It appears strip -o creates new files without preserving permissions from the source binary, resulting in non executable files. Signed-off-by: James Almer <jamrial@gmail.com> --- Untested. This is purely based on what i see in http://fate.ffmpeg.org/ Alternatively, although probably much harder to do, would be to make FATE run the fftools from the install folder rather than the build folder, which is what it's apparently doing right now. But that also only solves the issue for test/fate.sh and not for the resulting non execurable binary in the build folder. configure | 1 + 1 file changed, 1 insertion(+)