From: Norman V. <nh...@ca...> - 2001-12-15 16:00:13
|
Brian Ripley writes: > > >MinGW-1.1. > >If I use > >gcc -o Rterm.exe -luser -L. -lR Rterm.c What happens if you use ? gcc -o Rterm Rterm.c -L. -lR -luser see % > info ld Invocation Options " scroll down to '-lARCHIVE' entry for search order rules for libraries" Cheers Norman |
From: Prof B. R. <ri...@st...> - 2001-12-15 16:43:01
|
On Sat, 15 Dec 2001, Norman Vine wrote: > Brian Ripley writes: > > > > > >MinGW-1.1. > > > >If I use > > > >gcc -o Rterm.exe -luser -L. -lR Rterm.c [... by Normal Vine] > What happens if you use ? > > gcc -o Rterm Rterm.c -L. -lR -luser > > see > % > info ld Invocation Options > " scroll down to '-lARCHIVE' entry > for search order rules for libraries" The same. msvcrt.dll is not user32.dll (and I meant -luser32). If you use -v to give the complete ld line, -lmsvcrt comes after -lR, but which is searched first is dependent on what -lR is. (Giving R.dll explicitly is still after msvcrt.dll in the search.) Note: I've already read the ld manual, I know what it is supposed to do (and what it does on Linux and various Unix boxes). The issue is that ld behaves as expected if the -lARCHIVE references an import library, but *not* if it references a DLL. -- Brian D. Ripley, ri...@st... Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 |
From: <dan...@ya...> - 2001-12-15 20:24:52
|
--- Prof Brian Ripley <ri...@st...> wrote: > On Sat, 15 Dec 2001, Norman Vine wrote: > > > Brian Ripley writes: > > > > > > > > >MinGW-1.1. > > > > > >If I use > > > > > >gcc -o Rterm.exe -luser -L. -lR Rterm.c > > [... by Normal Vine] > > > What happens if you use ? > > > > gcc -o Rterm Rterm.c -L. -lR -luser > > > > see > > % > info ld Invocation Options > > " scroll down to '-lARCHIVE' entry > > for search order rules for libraries" > > The same. msvcrt.dll is not user32.dll (and I meant -luser32). > If you use -v to give the complete ld line, -lmsvcrt comes after -lR, > but which is searched first is dependent on what -lR is. (Giving R.dll > explicitly is still after msvcrt.dll in the search.) > > Note: I've already read the ld manual, I know what it is supposed to do > (and what it does on Linux and various Unix boxes). > > The issue is that ld behaves as expected if the -lARCHIVE references an > import library, but *not* if it references a DLL. > I think the problem is that the use of a DLL rather than an import lib as a lib reference is really just an add-on or a last resort. When you add R.dll as a lib, ld actually creates an import lib on the fly. I need to refresh myself with the source to see exactly what order things happen. If you think this is serious bug, you should probably report to binutils mailing list. Also I should note that the use of a DLL as lib reference will only work if all the symbols are unaliased functions. Data symbols and aliased stdcall functions may be reported as missing. Danny http://greetings.yahoo.com.au - Yahoo! Greetings - Send your festive greetings online! |