[bug-gnu-libiconv] Re: adding version identification to libiconv and libintl

[Bruno Haible]

Hello Perry,

> >And does that work also for shared libraries, i.e. can the .res file be
> >passed on the "libtool --mode=link gcc ... -o libiconv.la" command line?
> 
> I don't know. I'm not familiar with .la files, and didn't yet find a sample
> on the web.
> 
> I would have thought that the thing to do would be to put the resource
> into a dll.
> 
> It works in a completely straightforward manner in this fashion (I tested
> this and the version comes out successfully):
> 
> $ cat compile.sh
> gcc -c mydll.c
> windres -i mydll.rc --input-format=rc -o mydll.res -O coff
> gcc -shared -o mydll.dll mydll.res mydll.o
> 
> 
> Does that help any, or do you really want to know about libtool and
> ..la files?

This helps a lot; thanks. IIRC libtool passes all files with unknown
suffixes to the linker; this is exactly what we need here. I'll test it.

> >Before you send me the pieces, maybe one modification is possible: I would
> >guess that the makewinrc.sh does not require special tools, only normal
> >text processing tools (cat, sed, etc.)?
> 
> It just uses bash, but, I think it requires bash3 because of its use
> of BASH_REMATCH, like so:
> 
> == BEGIN QUOTE ==
> 
>   if [[ $VERSION =~ ([0-9]+)\.([0-9]+) ]]
>   then
>     VERSION1=${BASH_REMATCH[1]}
>     VERSION2=${BASH_REMATCH[2]}
>     VERSION3=0
>     VERSION4=0
> 
> == END QUOTE ==

We stick to POSIX 'sh' and tools. If you use bash3 syntax, I'll rewrite it
to use plain sh and 'sed'. The reference for POSIX sh is POSIX [1], combined
with the chapter on "portable shell programming" in the GNU autoconf manual.[2]
[1] http://www.opengroup.org/susv3/mindex.html
[2] http://www.gnu.org/software/autoconf/manual/autoconf.html#Portable-Shell

> >If this is true, there is an
> >opportunity to make the script invoke also $(WINDRES), to create the .res
> >file. This would reduce the modifications to the Makefile.am. (When 
> >possible,
> >one tries to put maximum functionality into helper scripts and have in the
> >Makefile.am only a minimum of logic.)
> 
> That makes sense. I should be able to do that.

Good, thanks. I wait for it.

> Ok, but, do you want it as an attachment emailed to the mailing list,
> or to you, or both, or uploaded to a patch board in some fashion?
> 
> (I know some people consider attachments rude
> on mailing lists, and some maintainers consider direct off-list email
> rude, so I'm asking first.)

Yes, usually people prefer inline patches to attachments in the mailing lists,
because it requires less effort to read them when browsing the archives. But
since we now know that your mailer tampers a patch's integrity when you
include it inline, better do it as an attachment.

We're currently CCing the mailing list; there is no good reason to stop
doing so, right before you publish the fruits of your work.

> >the executables were built for the "console" subsystem, IIRC. "windows"
> >subsystem is not a must?
> 
> Yes, that was just my imitating an existing solution

OK, good to know.

Thanks again.

Bruno