Re: [Mingw-w64-public] Unresolved symbols verses multiply defined symbols

[Patrick H. <pa...@13...>]

Kai Tietz wrote:
> Patrick,
>=20
> Patrick Hartling wrote on 12.09.2007 15:37:22:
>=20
>> Kai Tietz wrote:
>>> Hallo Patrick,
>>>
>>> Sorry that I anwser that late, but I had some vacation.
>> No problem. :) I hope that you had a good vacation.
>>
>>> You wrote:
>>>> In experimenting with 64-bit MinGW to create a 64-bit build of FFmpe=
g,=20
>>>> I ran into some rather unexpected problems when linking my code agai=
nst=20
>>>> FFmpeg and the MinGW libraries. For the 32-bit case, I have to link =

>>>> against these libraries: libavformat.a, libavcodec.a, libavutil.a,=20
>>>> libgcc.a, libmingwex.a, and ws2_32.lib. For the 64-bit case, I have =
to=20
>>>> link against those and libmsvcr80.a, libws2_32.a, libkernel32.a, and=
=20
>>>> libuser32.a to fix many unresolved symbols. I am not sure why I need=
 the=20
>>>> extra libraries for the 64-bit case, but I chalked it up to the MinG=
W w64=20
>>>> CRT being newer than the 32-bit version.
>>>
>>> The problem here is that MSVC uses the new (none OS crt msvcr80) but =
mingw=20
>>> uses msvcrt OS c runtime. This makes it a bit harder to mix VC and gc=
c=20
>>> generated object and library files. The mingw-w64 runtime depends on =

>>> msvcrt.dll. Therefore may try to get the ffmpeg built by VC as dll=20
>>> version,
>> Compiling FFmpeg using Visual C++ is not an option. I have tried, but =
the
>> amount of work involved in tweaking the code to be less tied to GCC se=
ems to
>> be much greater than what is involved in getting it to work in a 64-bi=
t
>> MinGW environment.
>>
>>> or try to compile the library as .a with gcc.
>> I have compiled it as a .a using GCC. I haven't tried running a test o=
f the
>> code on its own without involving Visual C++, however. The code that I=
 have
>> that utilizes the FFmpeg libraries requires the use of Visual C++.
>=20
> Is the use of ffmpeg as dll an option ?

It is, but I have not tried it yet. My toolchain has become unusable agai=
n,
and I have no idea what went wrong. I don't think I changed anything in i=
t,
but I can no longer link executables. Thus, the FFmpeg configure script
fails immediately. At this point, I feel that my next step is going to be=

removing my MinGW and MSYS installations and starting over from scratch.

>>> Otherwise you will=20
>>> have two runtimes and a lot of troubles (AITYH).
>> I certainly have. I don't quite understand how to avoid using multiple=

>> runtimes, though. Are you saying that by including libmingw32.a as inp=
ut to
>> the linker, I end up with multiple runtimes? Or is it simply the combi=
nation
>> of code compiled using GCC in the current 64-bit MinGW environment wit=
h code
>> compiled by Visual C++ 8.0 that causes multiple runtimes to be used?
>=20
> The only way to avoid this, would be to enforce on VC the use of=20
> msvcrt.dll instead.
> The option in mingw-w64 to use msvcr80.dll is currently not possible,=20
> because it is a none OS dll.

OK. I will pursue building FFmpeg as a DLL as soon as I can. My requireme=
nts
have changed, however, so this is not such a high priority now. I will
probably get back to it sometime within the next couple of months, though=
=2E

[snip]

>>>> BTW, I had to modify the file misc/gettimeofday.c in the w64 CRT sou=
rce=20
>>>> to remove the #if 0 block around the definition of gettimeofday() in=
 order=20
>>>> to fix one unresolved symbol. Is there a reason that this function i=
s not=20
>>>> being compiled in to the w64 CRT?
>>>
>>> This method is a POSIX one, and MS does not provide it. It is current=
ly=20
>>> just an experimental implementation in crt and not active.
>> Right, but I don't understand why it is not being compiled in to the C=
RT. Is
>> the implementation non-functional or otherwise broken? IIRC, gettimeof=
day()
>> is only referenced in one place in one of the FFmpeg libraries, and I =
do not
>> know how critical its use is. Commenting out that part of the FFmpeg c=
ode
>> might be an option, but it seems easier in general to compile in the
>> gettimeofday() implementation for the MinGW w64 CRT.
>=20
> The implementation in crt source works quite fine. It is disabled to av=
oid=20
> problems while building libiberty. This library brings its own=20
> gettimeofday implementation (a more poor one). I will make this functio=
n=20
> available on next release by exporting it as mingw_gettimeofday method.=
 On=20
> the otherhand you can use the method getntptimeofday instead. Insert it=
=20
> into a ,#ifdef _WIN64' clause. This should help too.

OK, thanks for the clarification. I can definitely do that.

>>>> [*] I have built the MinGW w64 CRT and FFmpeg using=20
>>>> -fno-leading-underscore.I posted a message about this issue on this =
list a=20
>>>> few days ago. I had modified some of the .def files in the CRT sourc=
e to=20
>>>> remove leading underscores manually, but I wasn't sure that this was=
=20
>>>> actually a wise thing to do, so I undid those changes and used the c=
hecked=20
>>>> in versions of the .def files. Thus, my w64 CRT is built using=20
>>>> -fno-leading-underscore with a modified misc/gettimeofday.c. Otherwi=
se, it=20
>>>> is an unmodified copy of Revision 55 from the SVN repository.
>>>
>>> The underscores are quite necessary. If you want to have the "old" (P=
OSIX)=20
>>> names use the oldnames library of mingw-w64.
>> The underscores in the .def files, or the underscores on all the symbo=
ls
>> generated by GCC? The FFmpeg libraries that I have built with GCC in t=
he
>> 64-bit MinGW environment are unusable with Visual C++ unless I compile=
 those
>> libraries and the MinGW w64 CRT with -fno-leading-underscore. I expect=
 that
>> this would be the case for any library compiled by GCC as a 64-bit bin=
ary
>> and then used in conjunction with 64-bit code compiled by Visual C++ 8=
=2E0. I
>> have not found documentation from Microsoft stating that the x64 platf=
orm
>> ABI does not use the leading underscore, but using nm on any 32- and 6=
4-bit
>> binaries compiled by Visual C++ 8.0 definitely shows the use of a lead=
ing
>> underscore as a difference in the C symbol naming.
>=20
> The underscores in MS crt are MS specific. They deprecated the POSIX=20
> naming and provide therefore the "oldnames" library.
>=20
> I think, the easiest solution for you would be to make a ffmpeg.dll and=
=20
> inherit that one into your vc project. You will still have two runtimes=
=20
> but they should disturb each other in to much places. The only importan=
t=20
> thing is to verify, that you are not freeing/mallocing in different crt=
s.

Thanks. This sounds very promising. I don't know when I will have an
opportunity to try it, but I will get back to it eventually.

 -Patrick


--=20
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/