Oleview: undefined references
Does anyone know why details.c and tree.c might have undefined references to the unicode string functions, such as strlenW()? My guess is that there might be something wrong with the Makefile.in. Compilation breaks if the -Write-strings flag is specified. Thanks, -- Andy.
On 6/21/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote:
Does anyone know why details.c and tree.c might have undefined references to the unicode string functions, such as strlenW()?
My guess is that there might be something wrong with the Makefile.in. Compilation breaks if the -Write-strings flag is specified.
I'm guessing you mean -Wwrite-strings. I don't know the answer to the question, but we should probably be using lstrlenW instead. -- James Hawkins
Andrew Talbot wrote:
Sorry, yes: compilation breaks if the -Wwrite-strings flag is specified.
If you configure with: CFLAGS="-Wwrite-strings" ./configure the configure script will not add -O2, which means inline function won't be inlined. The problem seems to be that oleview isn't linked with -llibwineunicode. Using lstrlenW() instead of strlenW() or adding $(LIBUNICODE) to Makefile.in should fix that. eg. EXTRALIBS = -luuid $(LIBUNICODE) Or you can just add -O2 yourself: CFLAGS="-Wwrite-strings -O2" ./configure Mike
Excellent. Thanks, Mike. I shall submit a patch to add $(LIBUNICODE) to the EXTRALIBS line. -- Andy.
On 6/21/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote:
Excellent. Thanks, Mike.
I shall submit a patch to add $(LIBUNICODE) to the EXTRALIBS line.
I personally think we should change the strlenW to lstrlenW. lstrlenW is win32, and doesn't require $(LIBUNICODE). Plus, we use it pretty much everywhere in the tree. -- James Hawkins
participants (3)
-
Andrew Talbot -
James Hawkins -
Mike McCormack