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

[amores perros]

> So it appears that a .res file can simply be added to the link command
> line, with the GNU linker just like I did years ago with the MSVC linker?

Yes, quite so.

> 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?


> > I don't know if you'd want to adapt this to gettext, but
> > if you'd like to, I'm more than happy to send you the pieces.
>
> 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 ==

I modified this from a variant that I use elsewhere,
which I found did not work for me on a system which
had a 2.x version of bash, if I remember correctly.
(I didn't have to fix it to work on that system, so I
did not change it.)

Is that a problem?

If it is, I'm sure the regexp parsing can be done in
another fashion -- there do seem to be a lot of
tools which do regexp on most GNU systems. I can
try to get something else working.


> 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.

> > I generated a context diff (diff -r -u3),
> > and am pasting it subsequently
>
> Your mailer added line breaking, which kills the ability to just feed the
> patch into "patch < ...". It should work better, I hope, if you attach
> the diffs as attachments.

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.)


> "diff -r -u3 --unidirectional-new-file" does it.

Great, I'll use this invocation.

> > -mwindows
>
> I hope this is unrelated to the .res files? In the older MSVC port of 
> gettext,
> the executables were built for the "console" subsystem, IIRC. "windows"
> subsystem is not a must?

Yes, that was just my imitating an existing solution, as was the use
of the flag for relocatable code.

_________________________________________________________________
Catch suspicious messages before you open them—with Windows Live Hotmail. 
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_protection_0507