[x265] v1.7+297: Unable to build multilib EXE, linker error
Steve Borho
steve at borho.org
Wed Jul 8 18:48:49 CEST 2015
On 07/08, Mario *LigH* Rohkr??mer wrote:
> Am 07.07.2015, 18:16 Uhr, schrieb Steve Borho <steve at borho.org>:
>
> >On 07/07, Mario *LigH* Rohkr??mer wrote:
> >>OK, compiling works now.
> >>
> >>But (if I didn't make another mistake) the created EXE does not export
> >>any
> >>functions (according to Microsoft PEScanner), and a DLL is still built.
> >
> >The (multilib or not) DLL is still expected to be built.
> >
> >But the EXE should be exporting the C symbols. Min checked this with
> >http://www.dependencywalker.com/ but its possible he only checked an
> >MSVC build. It's possible the mingw linker does not support def files
> >for executables (which would be unfortunate).
>
> It appears that the x265.def file is used to define additional exports *ONLY
> IF MSVC* is used.
>
> I tested expanding this clause to "MSVC OR GCC". It seems to work; at least
> PE analyzers are reporting exported functions now.
>
> If linking and using them works without crashing, I could not test, that's
> beyond my capabilities.
>
> +----
> diff -r 523540864864 source/CMakeLists.txt
> --- a/source/CMakeLists.txt Mon Jul 06 14:12:55 2015 +0530
> +++ b/source/CMakeLists.txt Wed Jul 08 09:10:10 2015 +0200
> @@ -524,9 +524,9 @@
> include_directories(compat/getopt)
> set(GETOPT compat/getopt/getopt.c compat/getopt/getopt.h)
> endif(NOT HAVE_GETOPT_H)
> - if(MSVC)
> + if(MSVC OR GCC)
> set(ExportDefs "${PROJECT_BINARY_DIR}/x265.def")
> - endif(MSVC)
> + endif(MSVC OR GCC)
indeed, how stupid of me. There is an MINGW flag we can use so we don't
break the linux build. http://www.cmake.org/Wiki/CMake_Useful_Variables
But now that I think on it more, it should just be WIN32, so MSVC,
MINGW, and INTEL will all use a def file for Windows executables.
--
Steve Borho
More information about the x265-devel
mailing list