www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - recls 1.8.11 on VC 7.1: makefile doesn't produce widechar binaries (+solution)

reply Jon Papaioannou <pj moodle.org> writes:
Hi! Please forgive the rather utilitarian format of this post, but I tried
first to send this as an email (it bounced), so... :)

PROBLEM:
I recently downloaded and built the excellent recls library to include its
functionality on a small Win32 utility I needed to make. However, when I
switched from multibyte to widechar builds for my utility, I noticed that
recls didn't work correctly (actually threw some exception, don't remember the
particulars).

CAUSE:
Debugging showed that this was because the (supposedly widechar) recls
binaries used plain "char" as the character type. Hashing the multibyte and
widechar library binaries confirmed that they were identical.

SOLUTION:
Therefore I delved into the makefile and saw that it simply... copied the
multibyte binaries to produce the widechar ones. I expanded and modified the
makefile to produce correct widechar builds and everything worked out fine.

QUESTION:
Are you aware of this behavior? Surely it can't be intended? I didn't check
the makefiles for other compilers, but quite possibly this "bug" exists in
these as well.

I can happily provide a patch for the makefile to save others some grief, if
you are willing to update the source packages.

In a related issue, the STLSoft 1.9.9 distribution has an error in the
source code which bit me during the widechar build:

stlsoft/filesystem/searchspec_sequence.hpp, line 168 reads:
   typedef string_tokeniser<string_type, char> tokeniser_type;

while it should read:
   typedef string_tokeniser<string_type, char_type> tokeniser_type;


Cheers,
Jon
Nov 26 2007
next sibling parent reply "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
Jon

Just wanted to give you a quick answer, to let you know I'm aware of your
post.

Will follow up shortly. (And, yes, the behaviour is not intended! ;-/)

One immediate question: what compiler(s) were you using? (If it's VC++ 8, I
think I may have an idea ...)

Cheers

Matt

"Jon Papaioannou" <pj moodle.org> wrote in message
news:fifhfm$2807$1 digitalmars.com...
 Hi! Please forgive the rather utilitarian format of this post, but I tried
 first to send this as an email (it bounced), so... :)

 PROBLEM:
 I recently downloaded and built the excellent recls library to include its
 functionality on a small Win32 utility I needed to make. However, when I
 switched from multibyte to widechar builds for my utility, I noticed that
 recls didn't work correctly (actually threw some exception, don't remember

 particulars).

 CAUSE:
 Debugging showed that this was because the (supposedly widechar) recls
 binaries used plain "char" as the character type. Hashing the multibyte

 widechar library binaries confirmed that they were identical.

 SOLUTION:
 Therefore I delved into the makefile and saw that it simply... copied the
 multibyte binaries to produce the widechar ones. I expanded and modified

 makefile to produce correct widechar builds and everything worked out

 QUESTION:
 Are you aware of this behavior? Surely it can't be intended? I didn't

 the makefiles for other compilers, but quite possibly this "bug" exists in
 these as well.

 I can happily provide a patch for the makefile to save others some grief,

 you are willing to update the source packages.

 In a related issue, the STLSoft 1.9.9 distribution has an error in the
 source code which bit me during the widechar build:

 stlsoft/filesystem/searchspec_sequence.hpp, line 168 reads:
    typedef string_tokeniser<string_type, char> tokeniser_type;

 while it should read:
    typedef string_tokeniser<string_type, char_type> tokeniser_type;


 Cheers,
 Jon

Nov 27 2007
parent reply Jon Papaioannou <pj moodle.org> writes:
Thanks for the heads up, Matt.

Looks like I managed to hide some data real good in the post title. ;-) Compiler
was VC++ 7.1 (verbatim: "Version 13.10.3077 for 80x86").

Cheers
Jon
Nov 29 2007
parent "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
LOL!


"Jon Papaioannou" <pj moodle.org> wrote in message
news:fimqe9$q92$1 digitalmars.com...
 Thanks for the heads up, Matt.

 Looks like I managed to hide some data real good in the post title. ;-)

 was VC++ 7.1 (verbatim: "Version 13.10.3077 for 80x86").

 Cheers
 Jon

Nov 29 2007
prev sibling next sibling parent "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
"Jon Papaioannou" <pj moodle.org> wrote in message
news:fifhfm$2807$1 digitalmars.com...
 Hi! Please forgive the rather utilitarian format of this post, but I tried
 first to send this as an email (it bounced), so... :)

 PROBLEM:
 I recently downloaded and built the excellent recls library to include its
 functionality on a small Win32 utility I needed to make. However, when I
 switched from multibyte to widechar builds for my utility, I noticed that
 recls didn't work correctly (actually threw some exception, don't remember

 particulars).

 CAUSE:
 Debugging showed that this was because the (supposedly widechar) recls
 binaries used plain "char" as the character type. Hashing the multibyte

 widechar library binaries confirmed that they were identical.

 SOLUTION:
 Therefore I delved into the makefile and saw that it simply... copied the
 multibyte binaries to produce the widechar ones. I expanded and modified

 makefile to produce correct widechar builds and everything worked out

 QUESTION:
 Are you aware of this behavior? Surely it can't be intended? I didn't

 the makefiles for other compilers, but quite possibly this "bug" exists in
 these as well.

 I can happily provide a patch for the makefile to save others some grief,

 you are willing to update the source packages.

John I'm having a hard time replicating this issue. Can you tell me your exact sequence of steps and/or send me through an example project (incl .vcproj) that illustrates? I'm really keen to fix this, in part because I want to move recls onto the 1.9 stream, but am unwilling to move until the 1.8 version is without issue. Cheers Matt
Dec 05 2007
prev sibling parent "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
This has finally been addressed, in v1.8.13. Download from http://recls.org/

FYI: recls development is now on the 1.9 stream, which will include some new
features, and a lot more order in the packaging, docs
and automated testing. Should start hitting the streets in August.

Cheers

Matt

"Jon Papaioannou" <pj moodle.org> wrote in message
news:fifhfm$2807$1 digitalmars.com...
 Hi! Please forgive the rather utilitarian format of this post, but I tried
 first to send this as an email (it bounced), so... :)

 PROBLEM:
 I recently downloaded and built the excellent recls library to include its
 functionality on a small Win32 utility I needed to make. However, when I
 switched from multibyte to widechar builds for my utility, I noticed that
 recls didn't work correctly (actually threw some exception, don't remember the
 particulars).

 CAUSE:
 Debugging showed that this was because the (supposedly widechar) recls
 binaries used plain "char" as the character type. Hashing the multibyte and
 widechar library binaries confirmed that they were identical.

 SOLUTION:
 Therefore I delved into the makefile and saw that it simply... copied the
 multibyte binaries to produce the widechar ones. I expanded and modified the
 makefile to produce correct widechar builds and everything worked out fine.

 QUESTION:
 Are you aware of this behavior? Surely it can't be intended? I didn't check
 the makefiles for other compilers, but quite possibly this "bug" exists in
 these as well.

 I can happily provide a patch for the makefile to save others some grief, if
 you are willing to update the source packages.

 In a related issue, the STLSoft 1.9.9 distribution has an error in the
 source code which bit me during the widechar build:

 stlsoft/filesystem/searchspec_sequence.hpp, line 168 reads:
    typedef string_tokeniser<string_type, char> tokeniser_type;

 while it should read:
    typedef string_tokeniser<string_type, char_type> tokeniser_type;


 Cheers,
 Jon

Jun 08 2008