similar to: [lld] Alias in COFF short import library.

> > The header of libuser32b.a says that it defines MessageBoxB and > __imp_MessageBoxB, but the import library file in the archive actually > defines MessageBoxA (not B). So the archive file is broken. You may want to > fix the header and try again. Yes this is how I done the alias. If you consider this invalid then look at libuser32.a The header defines MessageBoxA and

> > If you want to define an alias symbol "bar" to "foo" (which is an > extension you want to provide), one way is to create an object file that > defines "bar" and "__imp_bar" as aliases to "foo" and "__imp_foo", > respectively, and add that object file to the import library. As a result, > the import library file

Hey llvm'ers, I have been working on a dlltool replacement for llvm. Here is my initial differential https://reviews.llvm.org/D29892 It is based on some functionality that already exists in lld. I added functionality to support, PE COFF Weak Externals and of course a front end to actually use it. I believe the work here can also be used for llvm-lib and lessen the load on lld. I would like

Hey Rui, > I wonder how llvm-dlltool would fit in the entire picture of mingw > support. I don't think dlltool is the last missing piece. What do you need > to do other than that to fully support mingw using LLVM toolchain? Other then changing `lib/MC/WinCOFFStreamer.cpp` to not use -aligncomm within the EmitCommonSymbol function and a single patch for mingw-w64 itself to

> > Also you need to make a change to LLD/COFF to accept GNU command > arguments, right? (Looks like you already have that patch locally.) Yes > My patch to hack lld into accepting some very basic gnu front end > arguments was enough to get all the above working which was enough to > develop further. On Mon, Feb 13, 2017 at 8:41 PM, Rui Ueyama <ruiu at google.com>

> > I wonder if it can be a wrapper for LLD/COFF. It can be an in-process > wrapper, meaning that you could add a main function for mingw which > translates all arguments into the MSVC style and then invoke the COFF > linker's main function. That should work, if I am understanding this correctly I can create an argument parser (probably partially based on the ELF one) then I

> > No, I meant an even thinner wrapper which textually translates arguments. > For example, the wrapper would translates "/out:foo.exe foo.obj" to "-o > foo.exe foo.obj" and then call lld::COFFF:link(). It doesn't do anything > with Config object nor LinkerDriver::run and have absolutely zero knowledge > on the internals of LLD. Ohh okay I misunderstood.

On Mon, Feb 13, 2017 at 5:20 PM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Feb 13, 2017 at 4:46 PM, Martell Malone <martellmalone at gmail.com> > wrote: > >> No, I meant an even thinner wrapper which textually translates arguments. >>> For example, the wrapper would translates "/out:foo.exe foo.obj" to "-o

Ohh nice. With that method I can support it without upsetting ld users by introducing an api breakage. On Tue 14 Feb 2017 at 01:32, Rui Ueyama <ruiu at google.com> wrote: > On Mon, Feb 13, 2017 at 5:26 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > On Mon, Feb 13, 2017 at 5:20 PM, Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >

Yes, that would be the long term plan. llvm-link ideally would share the same library. I'm not sure where it should live though. On Tue 14 Feb 2017 at 01:49, Rui Ueyama <ruiu at google.com> wrote: > I took a look at the code. Looks like you need a library to create import > library files in LLVM and use that from llvm-dlltool and LLD. Is that what > you are planning? > >

Well that means it would just be the only plan then. I assume the first step would be to move the code from lld into this new library and lld can use that? I can then re add the extra functionality for weak externals? We can then have lib and dlltool use this then. On Tue 14 Feb 2017 at 01:58, Rui Ueyama <ruiu at google.com> wrote: > On Mon, Feb 13, 2017 at 5:56 PM, Martell Malone

Hi again rui, :) I've got all the patches into llvm and clang for supporting mingw-w64 via compiler-rt and now we are able to build a full mingw-w64 toolchain without gcc :) With great help from yaron and rnk. I've CC'd them as they might have interest in seeing this target through with me to the end :) So I have again turned my attention to LLD so that we can also remove ld as a

I forgot to attach the notes.txt with the objdump. On Thu, Jul 23, 2015 at 3:55 PM, Martell Malone <martellmalone at gmail.com> wrote: > Hi again rui, :) > > I've got all the patches into llvm and clang for supporting mingw-w64 via > compiler-rt and now we are able to build a full mingw-w64 toolchain without > gcc :) > With great help from yaron and rnk. > >

Hi Pavel, Right, my app also crashes in a different place under winedbg, although it crashes in the same winedbg place under gdb. I took a closer look at wine --winver nt40 --debugmsg +all. I found something interesting. If I search for queue_exception, I find that there is an exception raised before the LoadOEMCall, about 328klines in: 0806d398:Call

hello, i have this problem : [y.moya@yves y.moya]$ cd /mnt/cdrom [y.moya@yves cdrom]$ ls 3Dfx SETUP.EXE _setup.dll autorun.pak hlinst.dll setup.bmp DATA.TAG SETUP.INI _sys1.cab data1.cab lang.dat setup.ins DIRECTX Worldcraft _user1.cab dsetup.dll layout.bin setup.lid Localize.cab _INST32I.EX_ autorun.exe dsetup16.dll os.dat sierra.inf

Wine version: 20011108 CVS update run this morning Ran the following commands make uninstall make clean /tools/wineinstall Lotus Notes RNext running OK with latest CVS (I was having problems where buttons would not work), however if I go into User Preferences, and then click on either the OK or Cancel button, a crash occurs producing the following in the debugger.... WineDbg starting...

Hallo I got the error with newest CVS-Wine fixme:win32:PE_CreateModule Unknown directory 15 ignored err:module:Berr:module:BUILTINUILTIN32_dlopen failed to load .so lib for builtin user32.dll: undefined symbol: FT_Vector_Rotate err:module:PE_fixup_imports Module (file) user32.dll (which is needed by F:\Sateliti\AD3000Edit\AD3000Edit.exe) not found I can't use any Programm with Wine. --

Ubuntu 10.10 amd64 using ppa:ubuntu-wine/ppa wine version installed: wine1.3 1.3.6-0ubuntu1~maverickppa1 software in question: Pepakura Viewer 3.0.4 http://www.tamasoft.co.jp/pepakura-en/ http://www.tamasoft.co.jp/pepakura-en/download/setup_pepakura_viewer304_en.exe william at Origin:~$ winecfg wine: created the configuration directory '/home/william/.wine'

Hey guys, So I was able to modify dlltool to produce the exact same layout as lib.exe with the same section numbers etc. I've first managed to first create the correct section so that lld gives me link errors and then resolve those errors to create an exe. This is one thing that is still missing that sticks out like a sore thumb In the actual imports of the functions the objects are very

What is the status of support for directx2 apps? The "failed to create surface" error in MissionForce: Cyberstorm seems to have persisted forever... I have a +relay log of the said game launch session, (if somebody wants it, i can provide the full version) -- it appears that the graphics backend call pair which causes trouble is to winex11.drv.GetDCEx()/