On Tuesday 17 February 2009 12:11:47, Vincent R. wrote:
> When testing cegcc-4.4 when compiling a lib from EFL
> libtool: link: arm-mingw32ce-gcc -O3 -pipe -Wl,--enable-auto-import -Wl,-s
> -o .libs/evil_suite.exe evil_suite.o evil_test_dlfcn.o
> evil_test_environment.o evil_test_gettimeofday.o evil_test_link.o
> evil_test_memcpy.o evil_test_mkstemp.o evil_test_realpath.o
> memcpy_glibc_arm.o -L/home/vincent/local/wince/lib
> -L/home/vincent/toolchains/mingw32ce-4.4.0/lib
> ../../src/lib/.libs/libevil.a ../../src/lib/dlfcn/.libs/libdl.a
> /home/vincent/projects/efl/PROTO/evil/src/lib/.libs/libevil.a -lws2
> evil_suite.o:evil_suite.c:(.text+0x20): undefined reference to
> `__floatdidf'
> evil_suite.o:evil_suite.c:(.text+0x30): undefined reference to
> `__floatdidf'
>
> Any idea why ?
> Please note that from Vincent Torri explanation, libtool error message
> prepend a _ so actually linker cannot find
> _floatdidf function.
I'll take a look. Either that function isn't being linked in to libgcc,
or, it's being exported with the wrong underscores, maybe (CE is does not
get an extra underscore in C linkage function names, contrary to desktop
Windows,
or to most other ARM targets). Do you have a small testcase that shows
the failure?
> I may have an explanation, it seems libstdc++ shared lib is not built, I
> will check in this direction.
>
> I have also noticed some differences in mingw32.h, it seems that you have
> removed some stuff about shared libs
> because if I look at LINK_SPEC for instance
>
> I have the following
>
> #define LINK_SPEC "%{shared: %{mdll: %eshared and mdll are not compatible}}
> \
> %{shared: --shared} %{mdll:--dll} \
> %{static:-Bstatic} %{!static:-Bdynamic} \
> %{shared|mdll: -e DllMainCRTStartup} \
>
>
> and from your patch :
> #define LINK_SPEC "%{shared: --shared} \
> %{static:-Bstatic} %{!static:-Bdynamic} \
> %{shared|mdll: -e DllMainCRTStartup --enable-auto-image-base} \
> %(shared_libgcc_undefs)"
>
> ...
>
> During my investigations I noticed also that when I used
> --enable-auto-image-base, dll entry point
> was located at a wrong address but you seem to use it anyway.
I have no idea what you mean by wrong address here. But then
again, as I said, I haven't tried running anything built with this
toolchain yet. You were probably seeing the load base of the dll
had changed, and I thought that WinCE (at least <= 5, 6 maybe doesn't
due to the address space changes) ignored that PE setting anyway? Well, we
could remove that switch from the spec given this argument, but I'm curious
as to what was "wrong" --- since then it would be a linker bug to produce bad
images --- it should refuse to accept such a switch when outputting CE images.
> So my questions is have you removed %mdll on purpose or is it a mistake ?
>
It was on purpose, it doesn't make sense to have it for CE. But how does
this question derive from the earlier one about --enable-auto-image-base?
--
Pedro Alves
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
