[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