https://bugs.winehq.org/show_bug.cgi?id=37540
Bug ID: 37540 Summary: VCDS FRM 12.12.lnk Product: Wine Version: 1.6.2 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: jerometpc@gmail.com Distribution: ---
Unhandled exception: page fault on read access to 0x03b154c8 in 32-bit code (0x7bc1e300). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7bc1e300 ESP:0033fb7c EBP:0033fd38 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000000 EBX:03b152d8 ECX:00000214 EDX:00000000 ESI:0000000a EDI:03de0138 Stack dump: 0x0033fb7c: 7bc4b5a2 03de0138 00000000 00000214 0x0033fb8c: 7bc50656 0033fbac 00000000 00000100 0x0033fb9c: b7614f3d b77ac000 00110322 00000004 0x0033fbac: 00000000 03de0000 00000000 03de0000 0x0033fbbc: 00000214 7bcc3f27 7b8bddb4 00000000 0x0033fbcc: 03de0014 00000000 00000000 00000000 Backtrace: =>0 0x7bc1e300 in ntdll (+0xe300) (0x0033fd38) 1 0x7bc4b5a2 RtlAllocateHeap+0x6a1() in ntdll (0x0033fd38) 2 0x004ae74d in vcds (+0xae74c) (0x0033fd80) 3 0x004aab64 in vcds (+0xaab63) (0x0033fd9c) 4 0x004a5a0d in vcds (+0xa5a0c) (0x0033fe30) 5 0x00400000 (0x0033fd90) 0x7bc1e300: jmp *0x1f0(%ebx) Modules: Module Address Debug info Name (102 modules) PE 400000- 3691000 Export vcds PE 10000000-10033000 Deferred rt-usb ELF 7b800000-7ba5b000 Dwarf kernel32<elf> -PE 7b810000-7ba5b000 \ kernel32 ELF 7bc00000-7bcdb000 Dwarf ntdll<elf> -PE 7bc10000-7bcdb000 \ ntdll ELF 7bf00000-7bf04000 Deferred <wine-loader> ELF 7d530000-7d539000 Deferred librt.so.1 ELF 7d539000-7d540000 Deferred libffi.so.6 ELF 7d540000-7d558000 Deferred libresolv.so.2 ELF 7d558000-7d5a3000 Deferred libdbus-1.so.3 ELF 7d5a3000-7d5df000 Deferred libp11-kit.so.0 ELF 7d5df000-7d5f3000 Deferred libtasn1.so.6 ELF 7d5f3000-7d67a000 Deferred libgcrypt.so.11 ELF 7d67a000-7d6aa000 Deferred libk5crypto.so.3 ELF 7d6aa000-7d768000 Deferred libkrb5.so.3 ELF 7d768000-7d82e000 Deferred libgnutls.so.26 ELF 7d82e000-7d873000 Deferred libgssapi_krb5.so.2 ELF 7d873000-7d8e0000 Deferred libcups.so.2 ELF 7d8e0000-7da14000 Deferred libx11.so.6 ELF 7da72000-7da77000 Deferred libgpg-error.so.0 ELF 7da77000-7da7b000 Deferred libkeyutils.so.1 ELF 7da7b000-7da87000 Deferred libkrb5support.so.0 ELF 7da87000-7da99000 Deferred libavahi-client.so.3 ELF 7da9c000-7dab0000 Deferred shfolder<elf> -PE 7daa0000-7dab0000 \ shfolder ELF 7dab0000-7dae7000 Deferred uxtheme<elf> -PE 7dac0000-7dae7000 \ uxtheme ELF 7dae7000-7daed000 Deferred libxfixes.so.3 ELF 7daed000-7daf8000 Deferred libxcursor.so.1 ELF 7daf8000-7db09000 Deferred libxi.so.6 ELF 7db09000-7db0d000 Deferred libxcomposite.so.1 ELF 7db0d000-7db18000 Deferred libxrandr.so.2 ELF 7db18000-7db23000 Deferred libxrender.so.1 ELF 7db23000-7db29000 Deferred libxxf86vm.so.1 ELF 7db29000-7db2d000 Deferred libxinerama.so.1 ELF 7db2d000-7db34000 Deferred libxdmcp.so.6 ELF 7db34000-7db38000 Deferred libxau.so.6 ELF 7db38000-7db5a000 Deferred libxcb.so.1 ELF 7db5a000-7db6d000 Deferred libxext.so.6 ELF 7db6f000-7db74000 Deferred libcom_err.so.2 ELF 7db74000-7db82000 Deferred libavahi-common.so.3 ELF 7db84000-7dc16000 Deferred winex11<elf> -PE 7db90000-7dc16000 \ winex11 ELF 7dc5b000-7dc84000 Deferred libexpat.so.1 ELF 7dc84000-7dcbf000 Deferred libfontconfig.so.1 ELF 7dcbf000-7dce7000 Deferred libpng12.so.0 ELF 7dce7000-7dd87000 Deferred libfreetype.so.6 ELF 7dd87000-7ddaf000 Deferred mpr<elf> -PE 7dd90000-7ddaf000 \ mpr ELF 7ddaf000-7ddc9000 Deferred libz.so.1 ELF 7dde0000-7de5c000 Deferred wininet<elf> -PE 7ddf0000-7de5c000 \ wininet ELF 7de5c000-7de92000 Deferred ws2_32<elf> -PE 7de60000-7de92000 \ ws2_32 ELF 7de92000-7deb8000 Deferred iphlpapi<elf> -PE 7dea0000-7deb8000 \ iphlpapi ELF 7deb8000-7df87000 Deferred crypt32<elf> -PE 7dec0000-7df87000 \ crypt32 ELF 7df87000-7dfbe000 Deferred wintrust<elf> -PE 7df90000-7dfbe000 \ wintrust ELF 7dfbe000-7dffe000 Deferred winspool<elf> -PE 7dfd0000-7dffe000 \ winspool ELF 7dffe000-7e0e9000 Deferred comdlg32<elf> -PE 7e000000-7e0e9000 \ comdlg32 ELF 7e0e9000-7e114000 Deferred msacm32<elf> -PE 7e0f0000-7e114000 \ msacm32 ELF 7e114000-7e1ce000 Deferred winmm<elf> -PE 7e120000-7e1ce000 \ winmm ELF 7e1ce000-7e23f000 Deferred setupapi<elf> -PE 7e1e0000-7e23f000 \ setupapi ELF 7e265000-7e36c000 Deferred comctl32<elf> -PE 7e270000-7e36c000 \ comctl32 ELF 7e36c000-7e3e6000 Deferred shlwapi<elf> -PE 7e380000-7e3e6000 \ shlwapi ELF 7e3e6000-7e619000 Deferred shell32<elf> -PE 7e3f0000-7e619000 \ shell32 ELF 7e619000-7e69a000 Deferred rpcrt4<elf> -PE 7e620000-7e69a000 \ rpcrt4 ELF 7e69a000-7e7d6000 Deferred ole32<elf> -PE 7e6b0000-7e7d6000 \ ole32 ELF 7e7d6000-7e90c000 Deferred oleaut32<elf> -PE 7e7f0000-7e90c000 \ oleaut32 ELF 7e90c000-7e926000 Deferred version<elf> -PE 7e910000-7e926000 \ version ELF 7e926000-7e998000 Deferred advapi32<elf> -PE 7e930000-7e998000 \ advapi32 ELF 7e998000-7eab5000 Deferred gdi32<elf> -PE 7e9a0000-7eab5000 \ gdi32 ELF 7eab5000-7ec0f000 Deferred user32<elf> -PE 7ead0000-7ec0f000 \ user32 ELF 7ef7f000-7ef8c000 Deferred libnss_files.so.2 ELF 7ef8c000-7ef98000 Deferred libnss_nis.so.2 ELF 7ef98000-7efb1000 Deferred libnsl.so.1 ELF 7efb1000-7efba000 Deferred libnss_compat.so.2 ELF 7efba000-7f000000 Deferred libm.so.6 ELF b7422000-b75d2000 Deferred libc.so.6 ELF b75d2000-b75d7000 Deferred libdl.so.2 ELF b75d8000-b75f4000 Deferred libpthread.so.0 ELF b760b000-b77c0000 Dwarf libwine.so.1 ELF b77c2000-b77e4000 Deferred ld-linux.so.2 ELF b77e4000-b77e5000 Deferred [vdso].so Threads: process tid prio (all id:s are in hex) 0000000e services.exe 0000001e 0 0000001d 0 00000014 0 00000010 0 0000000f 0 00000012 winedevice.exe 0000001c 0 00000019 0 00000017 0 00000013 0 0000001a plugplay.exe 00000020 0 0000001f 0 0000001b 0 00000021 explorer.exe 00000023 0 00000022 0 0000003d VCDS.exe 00000040 0 0000003f 0 0000003e 0 00000041 winedbg.exe 00000042 0 00000045 (D) C:\Ross-Tech\VCDS-FRM\VCDS.exe 0000000b 0 00000047 0 00000046 0 <== System information: Wine build: wine-1.6.2 Platform: i386 Host system: Linux Host version: 3.13.0-37-generic
https://bugs.winehq.org/show_bug.cgi?id=37540
--- Comment #1 from Austin English austinenglish@gmail.com --- Please retest in 1.7.30. In the future, attach logs/backtraces, don't paste them.
Does this application have a demo/download available?
https://bugs.winehq.org/show_bug.cgi?id=37540
--- Comment #2 from jerometpc@gmail.com --- Good morning,
the URL download application :
http://www.ross-tech.com/vcds/download/current.html
https://bugs.winehq.org/show_bug.cgi?id=37540
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://www.ross-tech.com/vc | |ds/download/current.html Summary|VCDS FRM 12.12.lnk |VCDS crashes
https://bugs.winehq.org/show_bug.cgi?id=37540
Teras teras@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |teras@luukku.com
--- Comment #3 from Teras teras@luukku.com --- sha1sum VCDS-Release-14.10.1-Installer.exe ff1d63a056974f9c23d7b549bbb16f33fb226790 VCDS-Release-14.10.1-Installer.exe
24M
Backtrace: =>0 0x7bc1e4b0 in ntdll (+0xe4b0) (0x0033fcc8)
wine 1.7.36
https://bugs.winehq.org/show_bug.cgi?id=37540
Michael Weiser michael@weiser.dinsnail.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael@weiser.dinsnail.net
--- Comment #4 from Michael Weiser michael@weiser.dinsnail.net --- Hi,
I am hitting the same problem with 1.7.38 on OS X 10.10 built using osxwinebuilder. VCDS 11.11.4 works fine, versions 12.12.2 and 14.10.2 crash just as shown in the original report.
I have patching/compiling and some limited debugging known-how and can do testing of changes/patches if required.
Thanks, Michael
https://bugs.winehq.org/show_bug.cgi?id=37540
--- Comment #5 from Michael Weiser michael@weiser.dinsnail.net --- Created attachment 51518 --> https://bugs.winehq.org/attachment.cgi?id=51518 backtrace of VCDS-14.14.2 when started using wine 1.7.38 on OS X 10.10
Download URL: http://download.ross-tech.com/VCDS/download/EA31/VCDS-Release-14.10.2-Instal... MD5 (VCDS-Release-14.10.2-Installer.exe) = 0c4c36eff97d598c6f8d83e112e41fcf
https://bugs.winehq.org/show_bug.cgi?id=37540
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |obfuscation Status|UNCONFIRMED |NEW CC| |focht@gmx.net Summary|VCDS crashes |VCDS v12/v14 crashes on | |startup (Enigma Protector | |v4.0 DRM scheme | |incompatible with use of | |position independent code | |(PIC) in Wine dlls) Ever confirmed|0 |1
--- Comment #6 from Anastasius Focht focht@gmx.net --- Hello folks,
confirming.
The app is wrapped with Enigma Protector v4.0 DRM scheme.
--- snip --- -=[ ProtectionID v0.6.6.7 DECEMBER]=- (c) 2003-2015 CDKiLLER & TippeX Build 24/12/14-22:48:13 Ready... Scanning -> C:\Ross-Tech\VCDS\VCDS.EXE File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 2449664 (0256100h) Byte(s) Compilation TimeStamp : 0x54FEFA42 -> Tue 10th Mar 2015 14:05:54 (GMT) [TimeStamp] 0x54FEFA42 -> Tue 10th Mar 2015 14:05:54 (GMT) | PE Header | - | Offset: 0x00000110 | VA: 0x00400110 | - -> File Appears to be Digitally Signed @ Offset 0253E00h, size : 02300h / 08960 byte(s) [File Heuristics] -> Flag #1 : 00000000000001001100000100100110 (0x0004C126) [Entrypoint Section Entropy] : 8.00 (section #0) " " | Size : 0x62A00 (403968) byte(s) [DllCharacteristics] -> Flag : (0x8000) -> TSA [SectionCount] 7 (0x7) | ImageSize 0x4BED000 (79613952) byte(s) [Export] 0% of function(s) (0 of 1) are in file | 0 are forwarded | 0 code | 0 data | 0 uninit data | 0 unknown | [VersionInfo] Company Name : Ross-Tech. LLC [VersionInfo] Product Name : VCDS [VersionInfo] Product Version : 1410.2 [VersionInfo] File Description : VCDS [VersionInfo] File Version : 1410.2 [VersionInfo] Original FileName : VCDS.EXE [VersionInfo] Internal Name : VCDS [VersionInfo] Version Comments : VAG-COM Diagnostic System [VersionInfo] Legal Copyrights : Copyright (C) 2000-2015 Ross-Tech LLC/Uwe Ross [!] Enigma Protector v4.0 Build 2015/03/10 14:13:52 detected ! [!] Protected with a Company license (2) [i] File Analyser Deception feature usage [i] fake signature: Microsoft Visual C++ - Scan Took : 0.888 Second(s) [000000378h (888) tick(s)] [499 of 573 scan(s) done] --- snip ---
Unfortunately the way this DRM crap works is incompatible with Wine.
The protector code makes a full copy of relevant win32 API entries and uses indirect calls to those copied chunks, bypassing IAT. This can't work with PIC code where all GOT items require the constant offset to GOT to stay intact.
Likely a dupe of already existing bugs, such as bug 22600 or bugs from other DRM schemes doing the same thing.
IMHO a WONTFIX (or dupe of a WONTFIX).
$ sha1sum VCDS-Release-14.10.2-Installer.exe fc14448c0b229407bae2f97ae2fbeef879875ffe VCDS-Release-14.10.2-Installer.exe
$ du -sh VCDS-Release-14.10.2-Installer.exe 24M VCDS-Release-14.10.2-Installer.exe
$ wine --version wine-1.7.43-105-g9586d3b
Regards
https://bugs.winehq.org/show_bug.cgi?id=37540
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX
--- Comment #7 from Austin English austinenglish@gmail.com --- WONTFIX, per comment #6.
https://bugs.winehq.org/show_bug.cgi?id=37540
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael@fds-team.de
--- Comment #8 from Michael Müller michael@fds-team.de --- I am wondering if disabling PIC is not a valid solution for this problem. Without PIC the library needs to relocated (the same way as on windows) and Enigma can copy the functions without issues. I just compiled wine with "make CFLAGS=-fno-PIC" and the application starts without issues.
Is there any obvious disadvantage of disabling PIC, except that it might consume more memory?
https://bugs.winehq.org/show_bug.cgi?id=37540
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX |--- Summary|VCDS v12/v14 crashes on |Multiple games and |startup (Enigma Protector |applications wrapped with |v4.0 DRM scheme |Enigma v4 and GG DRM |incompatible with use of |schemes crash on startup |position independent code |(incompatible with use of |(PIC) in Wine dlls) |position independent code | |(PIC) in Wine dlls)
--- Comment #9 from Anastasius Focht focht@gmx.net --- Hello folks,
well, to be honest I didn't consider switching the default PIC build setting due to aforementioned drawback (trashes shared page usage/COW) and GCC problems/brokenness from the past (older GCC impl/code generation on x86_64 and ARMv7 architectures).
It might be useful to provide a non-PIC build of Wine-Staging for users to test/play with. The problem would be to sort out/identify issues resulting from that change from the usual bug/regression influx.
Ultimately it's up to AJ to switch the default setting ... and potentially the distro package maintainers (overriding the default).
Regards
https://bugs.winehq.org/show_bug.cgi?id=37540
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEW
--- Comment #10 from Anastasius Focht focht@gmx.net --- Hello folks again,
for a shared WoW64 Wine build (32-bit + 64-bit) you'll additionally need to pass '-mcmodel=large' to the 64-bit build CFLAGS.
This needed to avoid 'R_X86_64_PC32' linker errors (an invalid relocation for shared libraries on x64). Those are changed into R_X86_64_64 types for large memory model (absolute relocation with 64-bit value).
64-bit Total Commander runs fine here with no-PIC.
Regards
https://bugs.winehq.org/show_bug.cgi?id=37540
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=37540
--- Comment #11 from Michael Weiser michael@weiser.dinsnail.net --- Hi,
I tried re-compiling with -fno-PIC and -mcmodel=large using osxwinebuilder but get a relocation error on linking libwine.1.dylib:
ld: illegal text-relocation to '_dlldir' in config.o from '_get_dlldir' in config.o for architecture i386
I guess, OS X doesn't like no-PIC dynamic libs. For -mdynamic-no-pic it's explicitly documented in the man page - and clang even crashes when trying to compile wine using it.
Is there a Mac expert around who could help me out?
Thanks, Michael
Full call and error: michael@nindamos:~/bin/wine/build/wine-1.7.38 # PATH=/Users/michael/bin/wine/tools/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin make make[1]: Nothing to be done for `all'. version=`(GIT_DIR=../../.git git describe HEAD 2>/dev/null || echo "wine-1.7.38") | sed -n -e '$s/(.*)/const char wine_build[] = "\1";/p'` && (echo $version | cmp -s - version.c) || echo $version >version.c || (rm -f version.c && exit 1) ccache gcc -m32 -dynamiclib -install_name @rpath/libwine.1.dylib -Wl,-rpath,@loader_path/ -compatibility_version 1 -current_version 1.0 c_037.o c_10000.o c_10001.o c_10002.o c_10003.o c_10004.o c_10005.o c_10006.o c_10007.o c_10008.o c_10010.o c_10017.o c_10021.o c_10029.o c_1006.o c_10079.o c_10081.o c_10082.o c_1026.o c_1250.o c_1251.o c_1252.o c_1253.o c_1254.o c_1255.o c_1256.o c_1257.o c_1258.o c_1361.o c_20127.o c_20866.o c_20932.o c_21866.o c_28591.o c_28592.o c_28593.o c_28594.o c_28595.o c_28596.o c_28597.o c_28598.o c_28599.o c_28600.o c_28603.o c_28604.o c_28605.o c_28606.o c_424.o c_437.o c_500.o c_737.o c_775.o c_850.o c_852.o c_855.o c_856.o c_857.o c_860.o c_861.o c_862.o c_863.o c_864.o c_865.o c_866.o c_869.o c_874.o c_875.o c_878.o c_932.o c_936.o c_949.o c_950.o casemap.o collation.o compose.o config.o cptable.o debug.o fold.o ldt.o loader.o mbtowc.o mmap.o port.o sortkey.o string.o utf8.o wctomb.o wctype.o version.o ../../libs/port/libwine_port.a -framework CoreFoundation -framework CoreServices -L/Users/michael/bin/wine/wine-1.7.38/lib -L/opt/X11/lib -framework CoreServices -lz -L/opt/X11/lib -lGL -lGLU -o libwine.1.0.dylib ld: warning: could not create compact unwind for _wine_call_on_stack: dwarf uses DW_CFA_same_value ld: illegal text-relocation to '_dlldir' in config.o from '_get_dlldir' in config.o for architecture i386 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: *** [libwine.1.0.dylib] Error 1 make: *** [libs/wine] Error 2
https://bugs.winehq.org/show_bug.cgi?id=37540
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |envil@vexar.de
--- Comment #12 from Anastasius Focht focht@gmx.net --- *** Bug 22600 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=37540
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=35986
https://bugs.winehq.org/show_bug.cgi?id=37540
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maiktapwagner@aol.com
--- Comment #13 from Anastasius Focht focht@gmx.net --- *** Bug 39311 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=37540
--- Comment #14 from Austin English austinenglish@gmail.com --- (In reply to Michael Weiser from comment #11)
Hi,
I tried re-compiling with -fno-PIC and -mcmodel=large using osxwinebuilder but get a relocation error on linking libwine.1.dylib:
You shouldn't need -mcmodel=large, as wine64 doesn't work on OSX.
ld: illegal text-relocation to '_dlldir' in config.o from '_get_dlldir' in config.o for architecture i386
I guess, OS X doesn't like no-PIC dynamic libs. For -mdynamic-no-pic it's explicitly documented in the man page - and clang even crashes when trying to compile wine using it.
Is there a Mac expert around who could help me out?
I'm not an expert, but I do have google and a mac mini ;).
I made an basic patch for this and tested on Linux, then Mac. With mac, I see a similar error to you. I found posts suggesting -read_only_relocs suppress in LDFLAGS, so I tried that, but noticed the same failure. Then I found this on GMP's site:
A non-pic build using the 32-bit ABI on X86 provokes a linker bug. It is triggered by even a trivial hello.c program
@Ken, any suggestions? I'll attach my draft patch.
https://bugs.winehq.org/show_bug.cgi?id=37540
--- Comment #15 from Austin English austinenglish@gmail.com --- Created attachment 52401 --> https://bugs.winehq.org/attachment.cgi?id=52401 switch to -fno-PIC
https://bugs.winehq.org/show_bug.cgi?id=37540
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ken@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=37540
--- Comment #16 from Ken Thomases ken@codeweavers.com --- (In reply to Austin English from comment #14)
(In reply to Michael Weiser from comment #11)
I guess, OS X doesn't like no-PIC dynamic libs. For -mdynamic-no-pic it's explicitly documented in the man page - and clang even crashes when trying to compile wine using it.
Is there a Mac expert around who could help me out?
I'm not an expert, but I do have google and a mac mini ;).
I made an basic patch for this and tested on Linux, then Mac. With mac, I see a similar error to you. I found posts suggesting -read_only_relocs suppress in LDFLAGS, so I tried that, but noticed the same failure. Then I found this on GMP's site:
A non-pic build using the 32-bit ABI on X86 provokes a linker bug. It is triggered by even a trivial hello.c program
I wouldn't put too much stock in what that site says. It has completely bogus information about the object file format, for example.
We have no problem linking a final executable as non-position-independent. The wineloader is linked that way, using -Wl,-no_pie. So, I don't know what they're talking about regarding their trivial hello.c program. Of course, they are talking about ancient versions of Xcode, so there may have been a problem that's since been fixed.
@Ken, any suggestions? I'll attach my draft patch.
I think that Michael's conclusion that OS X just doesn't support non-PIC dynamic libraries is correct. I don't know if anything can be done about that.
https://bugs.winehq.org/show_bug.cgi?id=37540
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |james.patt@me.com
--- Comment #17 from Anastasius Focht focht@gmx.net --- *** Bug 39274 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=37540
--- Comment #18 from Michael Weiser michael@weiser.dinsnail.net --- Created attachment 53573 --> https://bugs.winehq.org/attachment.cgi?id=53573 Globally enable -mno-dynamic-pic on Darwin/OS X
I've now had time to revisit this problem for Darwin/OS X: With some quick googling I found hints that adding "-read_only_relocs suppress" works around the "illegal relocation" error from Xcode ld. The attached patch does this very hackishly and globally via appending to LDFLAGS. And indeed, this produces a wine-1.9.2 that is able to launch the current, still Enigma-wrapped version of VCDS (15.7.3) on OS X 10.11.3. Awesome!
https://bugs.winehq.org/show_bug.cgi?id=37540
--- Comment #19 from Michael Weiser michael@weiser.dinsnail.net --- Created attachment 53574 --> https://bugs.winehq.org/attachment.cgi?id=53574 Fully switch to no-PIC on Darwin/OS X
Looking at Austin's "switch to -fno-PIC" patch again I realize that the suppress read only relocs workaround is in there already but does not seem to carry far enough into all components of the build system.
One problem is that LIBWINE_LDFLAGS is set to "-multiply_defined suppress -read_only_relocs suppress" in the OS X host_os case but overwritten to "-dynamic ..." soon after.
Another seems to be that winegcc does not add "-read_only_relocs suppress" to the linker flags.
The attached patch fixes those problems and also makes wine compile cleanly into a no-PIC version that's able to run VCDS.
Due to conflicts some part of the patch concerning android and other platforms were rejected and are now missing from my patch. Should I rebase fully or can one of you have a look at it?
Thanks! Michael
https://bugs.winehq.org/show_bug.cgi?id=37540
--- Comment #20 from Austin English austinenglish@gmail.com --- I won't be able to for a couple weeks at the earliest, feel free to build on/submit my patch.
https://bugs.winehq.org/show_bug.cgi?id=37540
Michael Weiser michael@weiser.dinsnail.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #51518|0 |1 is obsolete| | Attachment #53573|0 |1 is obsolete| | Attachment #53574|0 |1 is obsolete| |
--- Comment #21 from Michael Weiser michael@weiser.dinsnail.net --- Created attachment 53575 --> https://bugs.winehq.org/attachment.cgi?id=53575 switch to -fno-PIC (2)
Here's the updated patch. It's tested on OS X 10.11.3 with wine-1.9.2.
It removes "-multiply_defined suppress" from LIBWINE_LDFLAGS because it could never have worked before and does not seem to be necessary anyways.
In winegcc.c it unconditionally enables passing of "-read_only_relocs suppress" to the Xcode linker which before was a downgrade to warning only on PowerPC.
https://bugs.winehq.org/show_bug.cgi?id=37540
Doug doug.bradley49@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |doug.bradley49@yahoo.com
https://bugs.winehq.org/show_bug.cgi?id=37540
Gabriel Ivăncescu gabrielopcode@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gabrielopcode@gmail.com
--- Comment #22 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Here's my take on this. 64-bit code has RIP-relative addressing. What this means is that position-independent code comes for free and is, in fact, the default even on Windows (mcmodel=large is much more bloated).
But that's only for 64-bit code. The thing is that -fPIC is terrible for 32-bit code. Not only do you waste a register (and you only have half compared to 64-bit) but also to get that register you need a call and then to fetch the return address, which is inefficient to say the least. So in fact -fno-PIC should be the default for 32-bit code, just like on Windows.
This DRM seems to be doing this for 32-bit code to begin with. I doubt it would assume -fno-PIC for 64-bit code since it would crash even on Windows most likely then.
Is it not possible to simply set -fno-PIC for 32-bit Wine only, while keeping -fPIC for 64-bit components? IMO, that would be the most correct behavior and is very likely how Windows is compiled itself, internally.
https://bugs.winehq.org/show_bug.cgi?id=37540
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=37540
zzzzzyzz@hacari.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzzzzyzz@hacari.org
https://bugs.winehq.org/show_bug.cgi?id=37540
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #23 from Zebediah Figura z.figura12@gmail.com --- Hello Anastasius, a couple questions:
(1) How does Enigma copy functions? Is getting rid of the GOT pointer really enough to make it work? Trying to copy an entire function is a very tenuous process, and it seems like it could easily break (if not now, then in the future) on things like assuming that the function is contiguous, or relative jmp/call, or TCO...
(2) Along the lines of comment 22, while x86-32 PIC is arguably not even worthwhile, x86-64 PIC is all but built in, and definitely more performant. AFAIU it won't be broken by hot-patching in the same way that x86 PIC is, but it could certainly be broken by function copying (unless, of course, the copier is smart enough to understand RIP-relative addressing). Is this a concern? Are you aware of schemes that might need -fno-PIC on x86-64? Though, if Gabriel is correct that Windows uses PIC there, I guess this is unlikely.
(2b) Similarly, what about ARM? (What does PIC even look like on ARM?)
https://bugs.winehq.org/show_bug.cgi?id=37540
--- Comment #24 from Gabriel Ivăncescu gabrielopcode@gmail.com --- To clarify: I don't know what exactly Windows does internally, I just based it on the fact that *compiled apps* for Windows have those defaults, even from code compiled with Visual Studio. So it's pretty safe to say Microsoft probably use the same defaults in their own code, but I don't think we'll ever know that for sure.
I definitely agree that -fPIC should be used on x86-64, just not on 32-bit code. Basically, we should have the same as default apps on Windows do (32-bit no-PIC, 64-bit PIC).
https://bugs.winehq.org/show_bug.cgi?id=37540
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED URL|http://www.ross-tech.com/vc |https://web.archive.org/web |ds/download/current.html |/20150415124943/http://down | |load.ross-tech.com/VCDS/dow | |nload/EA31/VCDS-Release-14. | |10.2-Installer.exe Resolution|--- |FIXED Fixed by SHA1| |8f732c66ab37b54c30d63c74f78 | |22ba1d4f04996 Component|-unknown |build-env
--- Comment #25 from Anastasius Focht focht@gmx.net --- Hello folks,
this is now fixed by following commits:
* https://source.winehq.org/git/wine.git/commitdiff/8f732c66ab37b54c30d63c74f7... ("makefiles: Build with -fno-PIC on i386.")
* https://source.winehq.org/git/wine.git/commitdiff/8039941c52758113955d376bd7... ("makefiles: Also pass -fPIC flag when linking.")
Thanks Zebediah and Alexandre.
Tested with:
https://web.archive.org/web/20150415124943/http://download.ross-tech.com/VCD...
* wine-4.7 release ('-fPIC' default for i386) -> crash * wine-4.7-66-g8039941c52 ('-fno-PIC' default for i386) -> Enigma v4 works as expected
$ sha1sum VCDS-Release-14.10.2-Installer.exe fc14448c0b229407bae2f97ae2fbeef879875ffe VCDS-Release-14.10.2-Installer.exe
$ du -sh VCDS-Release-14.10.2-Installer.exe 24M VCDS-Release-14.10.2-Installer.exe
Regards
https://bugs.winehq.org/show_bug.cgi?id=37540
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #26 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.8.
-
wine-bugs＠winehq.org