Menu
▾
▴
#682 CVS FTBFS with new mingw32
On Debian GNU/Linux, with mingw32 4.2.1, mingw32-runtime 3.13-1, nsis CVS, I get build failures:
i586-mingw32msvc-g++ -s -mwindows -Wl,--file-alignment,512 -Wl,-Map,build/release/BgImage/BgImage.map -Wl,-e_DllMain@12 -nostdlib -Wl,--exclude-libs,msvcrt.a -shared -o build/release/BgImage/BgImage.dll build/release/BgImage/BgImage.o -lkernel32 -luser32 -lgdi32 -lwinmm -Wl,--out-implib,build/release/BgImage/BgImage.lib -Wl,--output-def,build/release/BgImage/BgImage.def
Creating library file: build/release/BgImage/BgImage.libbuild/release/BgImage/BgImage.o: In function `SetBg':
/home/pabs/devel/misc/nsis/Contrib/BgImage/BgImage.cpp:155: undefined reference to `_memcpy'
/home/pabs/devel/misc/nsis/Contrib/BgImage/BgImage.cpp:156: undefined reference to `_memcpy'
/home/pabs/devel/misc/nsis/Contrib/BgImage/BgImage.cpp:157: undefined reference to `_memcpy'
collect2: ld returned 1 exit status
scons: *** [build/release/BgImage/BgImage.dll] Error 1
i586-mingw32msvc-g++ -o build/release/Library/RegTool/RegTool/RegTool.bin -mwindows -Wl,--file-alignment,512 -Wl,-e_WinMain@16 -nostdlib -Wl,--exclude-libs,msvcrt.a build/release/Library/RegTool/RegTool.o -lkernel32 -loleaut32 -ladvapi32 -luser32 -lole32
build/release/Library/RegTool/RegTool.o: In function `RunSelf':
/home/pabs/devel/misc/nsis/Contrib/Library/RegTool/RegTool.c:156: undefined reference to `_memset'
collect2: ld returned 1 exit status
scons: *** [build/release/Library/RegTool/RegTool/RegTool.bin] Error 1
i586-mingw32msvc-g++ -o build/release/stub_bzip2/stub_bzip2.exe -s -mwindows -nostdlib -Wl,--exclude-libs,msvcrt.a -Wl,--file-alignment,512 -Wl,-e,_WinMain@16 -Wl,-Map,build/release/stub_bzip2/stub_bzip2.map -T /home/pabs/devel/misc/nsis/SCons/Config/linker_script build/release/stub_bzip2/bgbg.o build/release/stub_bzip2/components.o build/release/stub_bzip2/exec.o build/release/stub_bzip2/fileform.o build/release/stub_bzip2/Main.o build/release/stub_bzip2/Ui.o build/release/stub_bzip2/util.o build/release/stub_bzip2/crc32.o build/release/stub_bzip2/bzlib.o build/release/stub_bzip2/decompress.o build/release/stub_bzip2/huffman.o build/release/stub_bzip2/resource.o -lkernel32 -luser32 -lgdi32 -lshell32 -ladvapi32 -lcomdlg32 -lcomctl32 -lole32 -lversion -luuid
build/release/stub_bzip2/exec.o: In function `ExecuteEntry':
/home/pabs/devel/misc/nsis/Source/exehead/exec.c:220: undefined reference to `_memcpy'
build/release/stub_bzip2/decompress.o: In function `BZ2_decompress@4':
/home/pabs/devel/misc/nsis/Source/bzip2/decompress.c:159: undefined reference to `_memcpy'
/home/pabs/devel/misc/nsis/Source/bzip2/decompress.c:501: undefined reference to `_memcpy'
collect2: ld returned 1 exit status
scons: *** [build/release/stub_bzip2/stub_bzip2.exe] Error 1
Logged In: YES
user_id=584402
Originator: NO
This should be detected by the configuration. Doesn't "Checking for memcpy..." say "Yes"? Can you attach config.log from a clean build?
config.log
Logged In: YES
user_id=35028
Originator: YES
Checking for memcpy requirement... no
Checking for memset requirement... no
File Added: config.log
Logged In: YES
user_id=584402
Originator: NO
That config.log is not from a clean build. Use scons --config=force or clean everything.
Logged In: YES
user_id=35028
Originator: YES
Hmm, thought I did scons -c and removed .scons* first.
Anyway, a log with --config=force is attached.
File Added: config.log
config.log with --config=force
Logged In: YES
user_id=584402
Originator: NO
Weird... It has the exact memcpy usage of SetBg in the test. Maybe it's some kind of a new optimization of gcc. Can you attach BgImage.o so I can look where exactly it uses memcpy? Also try adding two integers to the struct tested in SCons/Config/gnu line 210.
Logged In: YES
user_id=35028
Originator: YES
Attached BgImage.o
The change to the struct had no effect - tried both before and after the char array.
File Added: BgImage.o
BgImage.o
Logged In: YES
user_id=584402
Originator: NO
According to BgImage.o, it's the string initializations. Even weirder... Change:
if conf.CheckRequirement('memcpy', 'struct s { char c[128]; } t = { "test" };'):
To:
if conf.CheckRequirement('memcpy', 'struct s { char c[128]; } t = { "test" }; char t[] = {\'/\', \'T\', \'E\', \'S\', \'T\', 0};'):
And run it again with --config=force.
Logged In: YES
user_id=584402
Originator: NO
I got a bootstrapped sid and tested this myself. The problem was the optimization. It (rightfully) killed all the tests and always resulted with a simple xor eax, eax for main.