[Mingw-users] Mingw application fails to transfer from XP on PC1 to XP on PC2
djd
from the ...nix
environment to Windows XP using mingw.
To do this, I one-by-one linked the various *.c components, including
headers and library functions unavailable with
the standard mingw distribution (eg regex, regcomp, getline, uname,
libintl.a ...), then compiled the lot
with the -Wall option.
There were no complaints and the application worked!
I then copied the application to a second PC with the same version of XP
(according to the "ver" command),
but the application aborted.
During the compile on the original, I did not have any cause to think
there may be dynamic libraries included.
However to be sure, I installed the same distribution of mingw on the
second PC together with the additional libraries.
The application still aborted!
I copied the application from the second PC back to the original PC and
ran it. It was OK.
I would welcome any suggestions about what to do in order to discover
the cause of the problem on the
second PC.
Regards
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
MinGW-users mailing list
MinGW...@lists.sourceforge.net
This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-use...@lists.sourceforge.net?subject=unsubscribe
Eli Zaretskii
> From: djd <d...@cmad.com.au>
>
> There were no complaints and the application worked!
>
> I then copied the application to a second PC with the same version of XP
> (according to the "ver" command),
> but the application aborted.
Did it display any messages when it aborted?
Can you find anything interesting in the Event Viewer (most probably
in the Application part of it)?
djd
>> Date: Sun, 26 Feb 2012 17:49:16 +1100
>> From: djd<d...@cmad.com.au>
>>
>> There were no complaints and the application worked!
>>
>> I then copied the application to a second PC with the same version of XP
>> (according to the "ver" command),
>> but the application aborted.
> Did it display any messages when it aborted?
> Can you find anything interesting in the Event Viewer (most probably
> in the Application part of it)?
However, I discovered the problem: On the second PC, it certainly
required the installation of mingw because it was looking for
libintl-8.dll. Due to a missing path (my fault), it was not finding that
dll. So this application is not `XP transparent' and I guess could not
be, unless the required functions could be loaded into the application.
But if that is possible, I do not know how to achieve it. The -lintl
option is part of the compile script and there is a libintl.a and a
libintl.dll.a in the lib directory.
Alternatively, the Windows alternatives to using the function(s) in
libintl-8.dll would need to be found.
Regards
Earnie Boyd
>
> However, I discovered the problem: On the second PC, it certainly
> required the installation of mingw because it was looking for
> libintl-8.dll. Due to a missing path (my fault), it was not finding that
> dll. So this application is not `XP transparent' and I guess could not
> be, unless the required functions could be loaded into the application.
> But if that is possible, I do not know how to achieve it. The -lintl
> option is part of the compile script and there is a libintl.a and a
> libintl.dll.a in the lib directory.
>
> Alternatively, the Windows alternatives to using the function(s) in
> libintl-8.dll would need to be found.
>
Simply copy libintl-8.dll and any other dll that might be needed with
your program. If you distribute your program with these dll then you
will need to abide by the GPL and be willing to provide the source for
the version of the library you ship.
--
Earnie
-- https://sites.google.com/site/earnieboyd
Eli Zaretskii
> From: djd <d...@cmad.com.au>
>
> > Can you find anything interesting in the Event Viewer (most probably
> > in the Application part of it)?
> No idea what the Event Viewer is, will look it up.
Right-click on My Computer and select Manage, then expand "Event
Viewer" in the left pane of the window that opens.
> However, I discovered the problem: On the second PC, it certainly
> required the installation of mingw because it was looking for
> libintl-8.dll. Due to a missing path (my fault), it was not finding that
> dll. So this application is not `XP transparent' and I guess could not
> be
You need to install libintl-8.dll, Earnie told you how.
> unless the required functions could be loaded into the application.
> But if that is possible, I do not know how to achieve it. The -lintl
> option is part of the compile script and there is a libintl.a and a
> libintl.dll.a in the lib directory.
These are only useful if you rebuild the application yourself.
> Alternatively, the Windows alternatives to using the function(s) in
> libintl-8.dll would need to be found.
There isn't one.
Eli Zaretskii
> From: djd <d...@cmad.com.au>
>
> But, just a minute!
>
> The application runs `stand-alone' in the Linux environment, that is no
> run-time is required.
>
> Does this mean with any confidence that it should be able to run
> `stand-alone' in the XP environment?
It depends on how the program was built. Evidently, on Linux it was
statically linked against libintl functions (I think they are part of
the standard library on GNU/Linux), whereas on Windows it was linked
against a DLL.
> For example, could the compiled version be trying to load/run/use
> libintl-8.dll without actually requiring it?
No.
djd
>> Date: Thu, 01 Mar 2012 19:44:50 +1100
>> From: djd<d...@cmad.com.au>
>>
>> But, just a minute!
>>
>> The application runs `stand-alone' in the Linux environment, that is no
>> run-time is required.
>>
>> Does this mean with any confidence that it should be able to run
>> `stand-alone' in the XP environment?
> It depends on how the program was built. Evidently, on Linux it was
> statically linked against libintl functions (I think they are part of
> the standard library on GNU/Linux), whereas on Windows it was linked
> against a DLL.
required libintl functions?
Alternatively, could one:
a) Build a custom library which included the functions required?
or
b) Load the functions directly on the command line (as I have done with
a version of getline)?
Hans
> On 2/03/2012 4:39 AM, Eli Zaretskii wrote:
>>> Date: Thu, 01 Mar 2012 19:44:50 +1100
>>> From: djd<d...@cmad.com.au>
>>>
>>> But, just a minute!
>>>
>>> The application runs `stand-alone' in the Linux environment, that is no
>>> run-time is required.
>>>
>>> Does this mean with any confidence that it should be able to run
>>> `stand-alone' in the XP environment?
>> It depends on how the program was built. Evidently, on Linux it was
>> statically linked against libintl functions (I think they are part of
>> the standard library on GNU/Linux), whereas on Windows it was linked
>> against a DLL.
> Is there a way to do the same with mingw, that is statically link the
> required libintl functions?
>
> Alternatively, could one:
>
> a) Build a custom library which included the functions required?
>
> or
>
> b) Load the functions directly on the command line (as I have done with
> a version of getline)?
>
I use the Code::Blocks IDE on Linux and Windows 7 and had a similar
problem and solved it by statically linking the library functions:
Settings -> Compiler and Debugger -> Linker Settings.
In the Other Linker Options enter: -static-libgcc and/or the name of any
other library from which to statically link functions into your executable.
You may also need to
#define __MSVCRT_VERSION__ 0x0601 (or 0x0801) before
#include <stdlib.h>
#include <stdio.h>
etc. etc.
Hans
Eli Zaretskii
> From: djd <d...@cmad.com.au>
> CC: mingw...@lists.sourceforge.net
>
> > It depends on how the program was built. Evidently, on Linux it was
> > statically linked against libintl functions (I think they are part of
> > the standard library on GNU/Linux), whereas on Windows it was linked
> > against a DLL.
> Is there a way to do the same with mingw, that is statically link the
> required libintl functions?
Yes, of course: use the -static switch to GCC. By default, GCC will
prefer linking against a shared library; this switch prevents it from
doing that.
> Alternatively, could one:
>
> a) Build a custom library which included the functions required?
>
> or
>
> b) Load the functions directly on the command line (as I have done with
> a version of getline)?
I don't recommend such customizations when a much easier way is
already available and completely standard. The customizations that
you are considering will make it very hard for others to rebuild your
packages, which is a very important capability in the Free Software
community.
Earnie Boyd
>> Date: Fri, 02 Mar 2012 11:33:36 +1100
>> From: djd <d...@cmad.com.au>
>
>>
>> a) Build a custom library which included the functions required?
>>
>> or
>>
>> b) Load the functions directly on the command line (as I have done with
>> a version of getline)?
>
> I don't recommend such customizations when a much easier way is
> already available and completely standard. The customizations that
> you are considering will make it very hard for others to rebuild your
> packages, which is a very important capability in the Free Software
> community.
I also do not understand your angst against using a shared library.
You just need to make sure your binary package is complete with these
libraries. If I have foo.exe that I distribute and need bar.dll then
I put foo.exe in bin/ directory and bar.dll in bin/foo.exe.local/
directory as described by MSDN. If I have more than one binary
requiring a DLL then a manifest that adds a specific path to the
library search paths for the binaries as described in MSDN works. I
would put these in the bin/foo.exe.local/ directory and the manifest
for each binary points to the directory.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
--
Earnie
-- https://sites.google.com/site/earnieboyd
------------------------------------------------------------------------------
djd
> On Fri, Mar 2, 2012 at 4:04 AM, Eli Zaretskii<el...@gnu.org> wrote:
>>> Date: Fri, 02 Mar 2012 11:33:36 +1100
>>> From: djd<d...@cmad.com.au>
>>> Alternatively, could one:
>>>
>>> a) Build a custom library which included the functions required?
>>>
>>> or
>>>
>>> b) Load the functions directly on the command line (as I have done with
>>> a version of getline)?
>> I don't recommend such customizations when a much easier way is
>> already available and completely standard. The customizations that
>> you are considering will make it very hard for others to rebuild your
>> packages, which is a very important capability in the Free Software
>> community.
> I also do not understand your angst against using a shared library.
> You just need to make sure your binary package is complete with these
> libraries. If I have foo.exe that I distribute and need bar.dll then
> I put foo.exe in bin/ directory and bar.dll in bin/foo.exe.local/
> directory as described by MSDN. If I have more than one binary
> requiring a DLL then a manifest that adds a specific path to the
> library search paths for the binaries as described in MSDN works. I
> would put these in the bin/foo.exe.local/ directory and the manifest
> for each binary points to the directory.
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
for a while then forget about it
for months. In the meantime, I may have had to change PCs or work on a
different PC and the then application
needs to be recovered from somewhere. Inevitably, the need for an
ancillary file will have been forgotten
and hours are wasted wondering why it does not work anymore (the new PC?
The different version of OS? ...?).
I have been caught like that so many times I like to minimise potential
problems if I can.
I have just been reminded that there is a -static switch which hopefully
will resolve the issue.
Regards
Eli Zaretskii
> From: djd <d...@cmad.com.au>
>
> However, introduction of the switch introduced some compilation problems:
> Now, gcc is looking for a couple of functions in dcigettext.c in the
> mingw source path (which I did not
> download) and also a function in relocatable.c in the mingw source path.
>
> I guess I can obtain these and include them in the compile or is there
> another way?
The necessary libraries are probably already on your system, you just
need to add the necessary "-lFOO" switches to the link command line
(after you figure out which libraries are required). For example, to
get dcigettext, you need to add "-lintl".
P.S. And please don't remove the list from the addressees when you
reply, it forces me to manually add the address. This is a public
discussion; there's no need or reasons to convert it to a private one.
djd
>> Date: Sat, 03 Mar 2012 00:56:13 +1100
>> From: djd<d...@cmad.com.au>
>>
>> However, introduction of the switch introduced some compilation problems:
>> Now, gcc is looking for a couple of functions in dcigettext.c in the
>> mingw source path (which I did not
>> download) and also a function in relocatable.c in the mingw source path.
>>
>> I guess I can obtain these and include them in the compile or is there
>> another way?
> The necessary libraries are probably already on your system, you just
> need to add the necessary "-lFOO" switches to the link command line
> (after you figure out which libraries are required). For example, to
> get dcigettext, you need to add "-lintl".
-lintl has always
been present on the compile line. In fact, without it, the libintl-8.dll
is not found when the
-static switch is not used.
>
> P.S. And please don't remove the list from the addressees when you
> reply, it forces me to manually add the address. This is a public
> discussion; there's no need or reasons to convert it to a private one.
>
Don't know how the Mingw-users address disappeared.
Oh! I can see now. This (new to me) email client has a `Reply' and a
`Reply All' button.
I must have pressed the `Reply' button.
Regards
Eli Zaretskii
> From: djd <d...@cmad.com.au>
> CC: MinGW Users List <mingw...@lists.sourceforge.net>
>
> On 3/03/2012 2:15 AM, Eli Zaretskii wrote:
> >> Date: Sat, 03 Mar 2012 00:56:13 +1100
> >> From: djd<d...@cmad.com.au>
> >>
> >> However, introduction of the switch introduced some compilation problems:
> >> Now, gcc is looking for a couple of functions in dcigettext.c in the
> >> mingw source path (which I did not
> >> download) and also a function in relocatable.c in the mingw source path.
> >>
> >> I guess I can obtain these and include them in the compile or is there
> >> another way?
> > The necessary libraries are probably already on your system, you just
> > need to add the necessary "-lFOO" switches to the link command line
> > (after you figure out which libraries are required). For example, to
> > get dcigettext, you need to add "-lintl".
> The compiler requesting the *.c functions did puzzle me because the
> -lintl has always
> been present on the compile line. In fact, without it, the libintl-8.dll
> is not found when the
> -static switch is not used.
Of course: using -static tells the compiler to ignore the DLLs and
look for a file named libintl.a. Maybe you don't have it, in which
case you need to install the appropriate archive from the gettext
package.
What exactly was the error message displayed by the compiler?
djd
ls -l lib/libintl*
... 320692 Oct 22 03:49 lib/libintl.a
... 56108 Oct 22 03:49 lib/libintl.dll.a
... 915 Oct 22 04:03 lib/libintl.la
Without -static in the command line, there is no message from the
compiler, however if
the application is run without the mingw distribution installed, there
is a message
(I think from XP) indicating libintl-8.dll is missing. If the
application is run with that dll installed,
it is OK.
> What exactly was the error message displayed by the compiler?
>
>
With no other change but to insert -static into the command line (gcc
-Wall -static .... -lintl -o ...), the following is displayed:
c:/usr/bin/mingw/bin/../lib/gcc/mingw32/4.6.2/../../..\libintl.a(dcigettext.o):
In function `nl_find_msg':
c:/MinGW-src/gettext/gettext-0.18.1.1-2/src/gettext-0.18.1.1/gettext-tools/../gettext-runtime/intl/dcigettext.c:1306:
undefined reference to `libiconv'
c:/MinGW-src/gettext/gettext-0.18.1.1-2/src/gettext-0.18.1.1/gettext-tools/../gettext-runtime/intl/dcigettext.c:1174:
undefined reference to `libiconv_open'
c:/MinGW-src/gettext/gettext-0.18.1.1-2/src/gettext-0.18.1.1/gettext-tools/../gettext-runtime/intl/dcigettext.c:1168:
undefined reference to `libiconv_open'
c:/usr/bin/mingw/bin/../lib/gcc/mingw32/4.6.2/../../..\libintl.a(relocatable.o):
In function `libintl_set_relocation_prefix':
c:/MinGW-src/gettext/gettext-0.18.1.1-2/src/gettext-0.18.1.1/gettext-tools/../gettext-runtime/intl/relocatable.c:163:
undefined reference to `libiconv_set_relocation_prefix'
collect2: ld returned 1 exit status
Regards
Eli Zaretskii
> From: djd <d...@cmad.com.au>
> CC: mingw...@lists.sourceforge.net
>
> With no other change but to insert -static into the command line (gcc
> -Wall -static .... -lintl -o ...), the following is displayed:
>
> c:/usr/bin/mingw/bin/../lib/gcc/mingw32/4.6.2/../../..\libintl.a(dcigettext.o):
> In function `nl_find_msg':
> c:/MinGW-src/gettext/gettext-0.18.1.1-2/src/gettext-0.18.1.1/gettext-tools/../gettext-runtime/intl/dcigettext.c:1306:
> undefined reference to `libiconv'
> c:/MinGW-src/gettext/gettext-0.18.1.1-2/src/gettext-0.18.1.1/gettext-tools/../gettext-runtime/intl/dcigettext.c:1174:
> undefined reference to `libiconv_open'
> c:/MinGW-src/gettext/gettext-0.18.1.1-2/src/gettext-0.18.1.1/gettext-tools/../gettext-runtime/intl/dcigettext.c:1168:
> undefined reference to `libiconv_open'
> c:/usr/bin/mingw/bin/../lib/gcc/mingw32/4.6.2/../../..\libintl.a(relocatable.o):
> In function `libintl_set_relocation_prefix':
> c:/MinGW-src/gettext/gettext-0.18.1.1-2/src/gettext-0.18.1.1/gettext-tools/../gettext-runtime/intl/relocatable.c:163:
> undefined reference to `libiconv_set_relocation_prefix'
> collect2: ld returned 1 exit status
This is not about libintl, this is about a different library. The
crucial information is in these lines:
> undefined reference to `libiconv'
> undefined reference to `libiconv_open'
> undefined reference to `libiconv_set_relocation_prefix'
These functions are from libiconv, a different library. So to get
this to link, you should also add -liconv to the link command line.
(Put -liconv _after_ -lintl, since evidently libintl calls these
functions from libiconv, see above.)
djd
appear in libintl-8.dll?
With -static and -liconv inserted in the command line, the compile line
runs without error messages.
The application runs with the mingw distribution installed - as it
always has.
However, without the mingw installation (actually, renaming the mingw
directory as "xxxx"),
the application fails with a message window: "...failed to start because
libintl-8.dll was not found."
It would seem that the last few functions can be found in libintl-8.dll,
but no indication of what they may be.
Regards
Eli Zaretskii
> > this to link, you should also add -liconv to the link command line.
> > (Put -liconv _after_ -lintl, since evidently libintl calls these
> > functions from libiconv, see above.)
> >
> Strange that libiconv only show up when -static is used. They must also
> appear in libintl-8.dll?
Without -static, the linker doesn't try to resolve the run-time
dependencies of libintl. They are resolved when you run the
executable.
> With -static and -liconv inserted in the command line, the compile line
> runs without error messages.
> The application runs with the mingw distribution installed - as it
> always has.
> However, without the mingw installation (actually, renaming the mingw
> directory as "xxxx"),
> the application fails with a message window: "...failed to start because
> libintl-8.dll was not found."
Did you use _both_ -lintl and -liconv on the link command line, and
did you make sure they are specified in this order, i.e. first -lintl,
then -liconv?
> It would seem that the last few functions can be found in libintl-8.dll,
> but no indication of what they may be.
Under -static, the resulting executable should not depend on any DLL
that is not part of the Windows OS. Try this command:
objdump -s -x foo.exe | fgrep -i "dll name:"
where foo.exe is the name of the program you linked. This should show
you all the DLLs which the program needs. (Alternatively, you could
install depends.exe, which will show the same in pretty graphical
format.)
djd
>> Date: Sat, 03 Mar 2012 22:36:56 +1100
>> From: djd<d...@cmad.com.au>
>> CC: mingw...@lists.sourceforge.net
>>
>>> These functions are from libiconv, a different library. So to get
>>> this to link, you should also add -liconv to the link command line.
>>> (Put -liconv _after_ -lintl, since evidently libintl calls these
>>> functions from libiconv, see above.)
>>>
>> Strange that libiconv only show up when -static is used. They must also
>> appear in libintl-8.dll?
> Without -static, the linker doesn't try to resolve the run-time
> dependencies of libintl. They are resolved when you run the
> executable.
>
>> With -static and -liconv inserted in the command line, the compile line
>> runs without error messages.
>> The application runs with the mingw distribution installed - as it
>> always has.
>> However, without the mingw installation (actually, renaming the mingw
>> directory as "xxxx"),
>> the application fails with a message window: "...failed to start because
>> libintl-8.dll was not found."
> Did you use _both_ -lintl and -liconv on the link command line, and
> did you make sure they are specified in this order, i.e. first -lintl,
> then -liconv?
Copied from the command line: ... -lintl -lregex -liconv -o ...
>> It would seem that the last few functions can be found in libintl-8.dll,
>> but no indication of what they may be.
> Under -static, the resulting executable should not depend on any DLL
> that is not part of the Windows OS. Try this command:
>
> objdump -s -x foo.exe | fgrep -i "dll name:"
>
> where foo.exe is the name of the program you linked. This should show
> you all the DLLs which the program needs. (Alternatively, you could
> install depends.exe, which will show the same in pretty graphical
> format.)
Without the -static switch:
objdump -s -x convert.exe | fgrep -i "dll name:"
DLL Name: libintl-8.dll
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
DLL Name: msvcrt.dll
DLL Name: libgnurx-0.dll
With the -static switch:
objdump -s -x convert.exe | fgrep -i "dll name:"
DLL Name: ADVAPI32.DLL
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
DLL Name: msvcrt.dll
DLL Name: libgnurx-0.dll
Regards
Eli Zaretskii
> objdump -s -x convert.exe | fgrep -i "dll name:"
> DLL Name: ADVAPI32.DLL
> DLL Name: KERNEL32.dll
> DLL Name: msvcrt.dll
> DLL Name: msvcrt.dll
> DLL Name: libgnurx-0.dll
So you have one more linker switch to add: -lregex.
And I don't see how you could get an error regarding libintl-8.dll,
when this executable clearly does not depend on it, and neither does
libgnurx-0.dll.
Earnie Boyd
> Don't know how the Mingw-users address disappeared.
> Oh! I can see now. This (new to me) email client has a `Reply' and a
> `Reply All' button.
> I must have pressed the `Reply' button.
Then your client is broken since we munge the Reply-To header with the
list address. When I hit reply I get the list and nothing else.
--
Earnie
-- https://sites.google.com/site/earnieboyd
------------------------------------------------------------------------------
djd
> On Fri, Mar 2, 2012 at 6:44 PM, djd wrote:
>> Don't know how the Mingw-users address disappeared.
>> Oh! I can see now. This (new to me) email client has a `Reply' and a
>> `Reply All' button.
>> I must have pressed the `Reply' button.
> Then your client is broken since we munge the Reply-To header with the
> list address. When I hit reply I get the list and nothing else.
inserts all addresses.
The client is a recent version (10.0.2) of Thunderbird running on Win XP.
Regards
djd
>> Date: Sun, 04 Mar 2012 00:32:25 +1100
>> From: djd<d...@cmad.com.au>
>> CC:mingw...@lists.sourceforge.net
>>
>> With the -static switch:
>> objdump -s -x convert.exe | fgrep -i "dll name:"
>> DLL Name: ADVAPI32.DLL
>> DLL Name: KERNEL32.dll
>> DLL Name: msvcrt.dll
>> DLL Name: msvcrt.dll
>> DLL Name: libgnurx-0.dll
> So you have one more linker switch to add: -lregex.
That switch has been there all along. From a previous post;
> did you make sure they are specified in this order, i.e. first -lintl,
> then -liconv?
Copied from the command line: ... -lintl -lregex -liconv -o ...
> And I don't see how you could get an error regarding libintl-8.dll,
> when this executable clearly does not depend on it, and neither does
> libgnurx-0.dll.
>
Yes, you mentioned that if the -static switch is used, then no
non-windows dll would be included,
so I was surprised to find:
a) If the mingw distribution was `disabled' and then the application
run, it `aborted' with a message that
libintl-8.dll is missing - when it should not be there and was not
found by objdump.
I had been using some object files in the compile line, so I
started from `scratch' with all *.c files
and recompiled with -static. No -Wall warnings were issued and:
b) As previously, objdump reveals a non-windows dll, libgnurx-0.dll
even though the switch
-lregex is and always has been, after all *.c files on the compile
command line.
With the mingw distribution intact, the application runs OK
With the mingw distribution disabled, the application aborts with the
message ...libgnurx-0.dll not found.
(For an unknown reason, except a fresh compile form all *.c files, this
time it was not libintl-8.dll that was
reported as missing)
The is consistent with objdump reporting the presence of libgnurx-0.dll
and the application aborting when
libgnurx-0.dll is disabled, but apparently inconsistent with compiling
with the -static switch.
Regards
Keith Marshall
>>> I must have pressed the `Reply' button.
>>
>> Then your client is broken since we munge the Reply-To header with the
>> list address. When I hit reply I get the list and nothing else.
Provided that *only* the list address is enumerated in the 'Reply-To'
header; this isn't always the case.
> It seems logical: `Reply' inserts only the sender's address,
That's a naive presumption. 'Reply' *should* send replies to any and
*all* addresses enumerated in the 'Reply-To' header; only in cases when
this header isn't present, should it use the single address specified in
the 'From' header -- i.e. the sender's address.
We munge the 'Reply-To' header, so that it will always include the list
address, but we don't remove any addresses which are already present in
such a header, if it pre-exists. In Eli's messages, I see:
Reply-To: el...@address.hidden, mingw...@lists.sourceforge.net
so he gets direct replies, bypassing the list; there is no guarantee
that these will have a 'Reply-To' header, but if they do, it is quite
possible that they may not include the list address. This practice of
adding your own 'Reply-To' header, without ensuring that it specifies
the list address, may ultimately lead to the list being accidentally
dropped from a continuing dialogue.
> `Reply All' inserts all addresses.
As listed in 'Reply-To' and 'Cc' headers, IIRC; (consult the relevant
RFC yourself, if you want confirmation).
> The client is a recent version (10.0.2) of Thunderbird running on Win
> XP.
It's unlikely that this is broken. It should also offer a 'Reply-List'
option, for messages originating from a mailing list, (specifically
those which have a 'List-Post' header); that's the best choice, when it
is available, (and when it isn't, you are responding to a message which
has been sent to you directly, bypassing the list).
--
Regards,
Keith.
djd
> It's unlikely that this is broken. It should also offer a 'Reply-List'
> option, for messages originating from a mailing list, (specifically
> those which have a 'List-Post' header); that's the best choice, when it
> is available, (and when it isn't, you are responding to a message which
> has been sent to you directly, bypassing the list).
button displayed `Reply List'
So it does know. Way back, I did not realise there was an extra reply
button. But I know now.
Regards
Eli Zaretskii
>
> That switch has been there all along. From a previous post;
>
> > did you make sure they are specified in this order, i.e. first -lintl,
> > then -liconv?
>
> Copied from the command line: ... -lintl -lregex -liconv -o ...
Do you have a file named libregex.a in your MinGW lib/ subdirectory?
I'm guessing you don't. I think you have there only libregex.dll.a or
some such, which is an import library that instructs the executable to
load libgnurx-0.dll at run time. IOW, without libregex.a, you cannot
do a completely static build.
If my guess is correct, you need to download and install
mingw-libgnurx-X.Y.Z-dev package from the MinGW site.
If my guess is incorrect, then please add -v to the link command line,
and post here everything that the compiler prints while linking with
the -static switch.
djd
>> Date: Sun, 04 Mar 2012 15:20:08 +1100
>> From: djd<d...@cmad.com.au>
>> CC: mingw...@lists.sourceforge.net
>>
>>> So you have one more linker switch to add: -lregex.
>> That switch has been there all along. From a previous post;
>>
>>> did you make sure they are specified in this order, i.e. first -lintl,
>>> then -liconv?
>> Copied from the command line: ... -lintl -lregex -liconv -o ...
> Do you have a file named libregex.a in your MinGW lib/ subdirectory?
> I'm guessing you don't. I think you have there only libregex.dll.a or
> some such, which is an import library that instructs the executable to
> load libgnurx-0.dll at run time. IOW, without libregex.a, you cannot
> do a completely static build.
the same size as
libgnurx.dll.a. I just now tried a binary compare (cmp libregex.a
libgnurx.dll.a) - they are identical???
These came in one tar file (mingw-libgnurx-2.5.1-dev.tar.gz) and I think
the source was Source Forge..
It would seem someone has merely copied libgnurx.dll.a to libregex.a in
order to avoid gcc warnings
when the -static switch is used, which is not `nice'. One may have
tested, thinking the application
was `stand-alone' and distribute it to others who know nothing about
mingw. But, what was thought
to work, no longer works for those others.
A pertinent point. Will a warning be issued if the -static switch is set
and a relevant *.a
is missing, however the run-time version is present?
> If my guess is correct, you need to download and install
> mingw-libgnurx-X.Y.Z-dev package from the MinGW site.
I assume by `MinGW site, you mean `Source Forge' which is where I am
fairy sure I obtained
the regex libraries. Nevertheless, I will look for another MinGW site.
> If my guess is incorrect, then please add -v to the link command line,
> and post here everything that the compiler prints while linking with
> the -static switch.
>
>
Your guess was incorrect, but clouded by the issue that libregex.a is
just a copy of libgnurx.dll.a.
Do you still want the -v output?
Regards
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
Eli Zaretskii
> the same size as
> libgnurx.dll.a. I just now tried a binary compare (cmp libregex.a
> libgnurx.dll.a) - they are identical???
That must be the reason, then: you don't actually have a static regex
library, thus the linker has no choice but to leave the regex library
dynamically loaded.
> A pertinent point. Will a warning be issued if the -static switch is
> set and a relevant *.a is missing, however the run-time version is
> present?
Well, you already know the answer to that, since you were in exactly
this position, and saw what happens ;-)
> Your guess was incorrect, but clouded by the issue that libregex.a is
> just a copy of libgnurx.dll.a.
> Do you still want the -v output?
No. I guess you'll need to get the sources of that mingw-libgnurx
package and build the static library yourself, to solve this.
Sergio NNX
> this position, and saw what happens ;-)
>
> > Your guess was incorrect, but clouded by the issue that libregex.a is
> > just a copy of libgnurx.dll.a.
> > Do you still want the -v output?
>
> No. I guess you'll need to get the sources of that mingw-libgnurx
> package and build the static library yourself, to solve this.
We seem to be going around in circles here. Is it possible to have access to this app source code so I can have a go at it?
Cheers.
djd
need for a `genuine' static libregex.a - except I did not realise it was not `genuine'. However, I am not
complaining, the only c program I have ever compiled previously, maybe 30 years ago, was "Hello word"
and I have never used mingw or gcc. I have learnt a lot through this exercise.
I have attached two files, the original source uni2ascii.zip (its on the internet somewhere) and my modified
version. Originally I tried using the configure script included in uni2ascii.zip, however after much trying, it was
just too convoluted (for me) to easily work out what was going on, so I went back to the original *.c files and
started again.
That meant obtaining some additional source (getline, win32-uname, ...) and headers and I temporarily
renamed the output convert.exe to avoid confusing myself. All these *.c files are in convert.zip and most of the
extra headers plus the compile line I have been using. But some of the additional headers are in their
usual directories and I cannot immediately remember what they were. However if they are not obvious
to you, I am sure I can work it out.
And thanks to Eli Zaretskii for his knowledge and doggedness in sticking with me when I must have
appeared appallingly clueless to him.
Regards
Keith Marshall
> Yes, there is a libregex.a. However it is `suspicious' as it is
> exactly the same size as libgnurx.dll.a. I just now tried a binary
> compare (cmp libregex.a libgnurx.dll.a) - they are identical???
>
> These came in one tar file (mingw-libgnurx-2.5.1-dev.tar.gz) and I
> think the source was Source Forge..
It's not one of our officially supported packages, but I guess you've
found it amongst our collection of unsupported user-contributed packages.
> It would seem someone has merely copied libgnurx.dll.a to libregex.a
> in order to avoid gcc warnings when the -static switch is used, which
> is not `nice'.
Nice or not, it's what the original contributor intended; he says as
much, in the README file within the corresponding source package.
> One may have tested, thinking the application was `stand-alone' and
> distribute it to others who know nothing about mingw. But, what was
> thought to work, no longer works for those others.
No, that isn't the case at all. As that README makes very clear, the
DLL is called libgnurx-0.dll to introduce DLL versioning, while also
avoiding potential name collisions with incompatible offerings from the
GnuWin32 project; libgnurx.dll.a is the naturally named import library
to accompany it, and libregex.a is a COPY of that same import library,
to accommodate build scripts or makefiles which link with -lregex.
It is perfectly clear that this package was never intended to support
static linking.
Now, had I been the contributor, I would likely have named the second
import library as libregex.dll.a, (which still provides the capability
for linking with -lregex), and could then have offered libregex.a as a
statically linkable library. However, this package may be a throwback
to a time when this duality of naming was not supported; for whatever
reason, the original contributor chose to offer only a dynamically
linkable library.
>> If my guess is correct, you need to download and install
>> mingw-libgnurx-X.Y.Z-dev package from the MinGW site.
No; that's likely just what you've got already. You need to download
the source package, and rebuild as a statically linkable library.
FWIW, this all seems like a lot of unnecessary effort, just to avoid
packing the EXE and all of it's DLL requisites into a single archive, so
they can be installed as a single unit.
> I assume by `MinGW site, you mean `Source Forge' which is where I am
> fairy[sic] sure I obtained the regex libraries.
All official (and user-contributed) MinGW downloads are hosted on the
MinGW project pages at SourceForge, so yes, that's what Eli means.
> Nevertheless, I will look for another MinGW site.
There isn't one, other than MinGW.org, which will refer you back to the
SourceForge host, for downloads.
--
Regards,
Keith.
Eli Zaretskii
> Date: Mon, 5 Mar 2012 07:32:28 +0000
> Cc: mingw...@lists.sourceforge.net
>
> > I guess you'll need to get the sources of that mingw-libgnurx
> > package and build the static library yourself, to solve this.
>
FWIW, I see no circle here. In fact, this thread just solved the
original problem, by concluding that a static regex library is needed
to accomplish the OP's goal of having a stand-alone program. All that
remains is to get hands on the regex sources and that's it.