Project

General

Profile

Bug #2833

http::server::buffer_string::icontains link error with WT 3.3.2

Added by Cynthia Donato over 8 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
-
Start date:
03/20/2014
Due date:
% Done:

0%

Estimated time:

Description

hello,

I was previously using wt 3.2.3 for development of an application. I just switched over to wt3.3.2 and am now experienceing the following link error:

error LNK2019: unresolved external symbol __imp_StrStrIA referenced in function "public: bool __cdecl http::server::buffer_string::icontains(char const *)const " (?icontainsbuffer\_string@server@http@@QEBA\_NPEBDZ)

Any guidance as to how to resolve this issue would be greatly appreciated.

Thanks

#1

Updated by Eivind Midtgård over 8 years ago

You need to link with shlwapi.lib

Regards,

Eivind

#2

Updated by Cynthia Donato over 8 years ago

thank you that fixed the issue.

Much appreciated :)

#3

Updated by Koen Deforche over 8 years ago

  • Status changed from New to InProgress
  • Assignee set to Wim Dumon
  • Target version set to 3.3.3

Is this something we should add in the linking of wthttpd?

#4

Updated by Koen Deforche over 8 years ago

  • Target version deleted (3.3.3)
#5

Updated by Cynthia Donato over 8 years ago

Adding the shlwapi.lib to my qmake file solved the issue. I believe it should be added to the linking of the wthttpd but in my case it's not a show stopper.

#6

Updated by Eivind Midtgård over 8 years ago

Why not use boost::icontains and boost::iequals instead of strcasestr and strcasecmp?

#7

Updated by Wim Dumon over 8 years ago

The reason why we changed it is performance. This should be a pure ASCII strstr, so locales don't matter.

BR,

Wim.

#8

Updated by Boris Savelev over 8 years ago

Wim Dumon wrote:

The reason why we changed it is performance. This should be a pure ASCII strstr, so locales don't matter.

BR,

Wim.

Hello!

Using `strcasestr` will brake compilation on Solaris (Solaris haven't strcasestr)

#9

Updated by Wim Dumon over 8 years ago

  • Status changed from InProgress to Resolved

since these functions cause such headaches, I modified the code to use boost methods unless we know they exist. Their existance is tested by cmake.

The 'performance issue' is not really an issue after all, only makes Wt better for benchmarks.

Wim.

#10

Updated by Koen Deforche about 8 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF