From: djd <dj...@cm...> - 2012-02-26 06:49:35
|
As a beginner with both c and mingw, I attempted moving an application 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 |
From: Eli Z. <el...@gn...> - 2012-02-26 16:50:57
|
> Date: Sun, 26 Feb 2012 17:49:16 +1100 > From: djd <dj...@cm...> > > 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)? |
From: djd <dj...@cm...> - 2012-02-29 05:27:11
|
On 27/02/2012 3:52 AM, Eli Zaretskii wrote: >> Date: Sun, 26 Feb 2012 17:49:16 +1100 >> From: djd<dj...@cm...> >> >> 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? Nothing other than essentially `ABORTED' > 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. 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 |
From: Earnie B. <ea...@us...> - 2012-02-29 13:27:58
|
On Wed, Feb 29, 2012 at 12:26 AM, djd wrote: > > 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 |
From: Eli Z. <el...@gn...> - 2012-02-29 17:22:59
|
> Date: Wed, 29 Feb 2012 16:26:56 +1100 > From: djd <dj...@cm...> > > > 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. |
From: Eli Z. <el...@gn...> - 2012-03-01 17:37:44
|
> Date: Thu, 01 Mar 2012 19:44:50 +1100 > From: djd <dj...@cm...> > > 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. |
From: djd <dj...@cm...> - 2012-03-02 00:33:54
|
On 2/03/2012 4:39 AM, Eli Zaretskii wrote: >> Date: Thu, 01 Mar 2012 19:44:50 +1100 >> From: djd<dj...@cm...> >> >> 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)? |
From: Hans <li...@in...> - 2012-03-02 04:10:12
|
On 02/03/12 10:33, djd wrote: > On 2/03/2012 4:39 AM, Eli Zaretskii wrote: >>> Date: Thu, 01 Mar 2012 19:44:50 +1100 >>> From: djd<dj...@cm...> >>> >>> 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 |
From: Eli Z. <el...@gn...> - 2012-03-02 09:02:11
|
> Date: Fri, 02 Mar 2012 11:33:36 +1100 > From: djd <dj...@cm...> > CC: min...@li... > > > 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. |
From: Eli Z. <el...@gn...> - 2012-03-02 15:13:16
|
> Date: Sat, 03 Mar 2012 00:56:13 +1100 > From: djd <dj...@cm...> > > 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. |
From: djd <dj...@cm...> - 2012-03-02 23:44:18
|
On 3/03/2012 2:15 AM, Eli Zaretskii wrote: >> Date: Sat, 03 Mar 2012 00:56:13 +1100 >> From: djd<dj...@cm...> >> >> 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. > > 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 |
From: Earnie B. <ea...@us...> - 2012-03-03 17:19:22
|
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. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: djd <dj...@cm...> - 2012-03-04 01:21:51
|
On 4/03/2012 4:19 AM, Earnie Boyd wrote: > 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. It seems logical: `Reply' inserts only the sender's address, `Reply All' inserts all addresses. The client is a recent version (10.0.2) of Thunderbird running on Win XP. Regards |
From: Keith M. <kei...@us...> - 2012-03-04 11:01:15
|
On 04/03/12 01:21, djd wrote: >>> 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: eliz@address.hidden, min...@li... 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. |
From: djd <dj...@cm...> - 2012-03-04 11:15:40
|
On 4/03/2012 10:01 PM, Keith Marshall wrote: > 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). Interesting. In the case of replying to this message, the `Reply all' 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 |
From: Cesar R. <ces...@gm...> - 2012-04-30 21:25:58
|
On 04/03/2012 06:15 a.m., djd wrote: > On 4/03/2012 10:01 PM, Keith Marshall wrote: >> 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). > Interesting. In the case of replying to this message, the `Reply all' > button displayed `Reply List' > So it does know. Way back, I did not realise there was an extra reply > button. But I know now. Hi djd, I built a static regex library. Download libregex.tar.gz from: https://skydrive.live.com/?sc=documents&cid=aa6e98f91163abaf#cid=AA6E98F91163ABAF&id=AA6E98F91163ABAF%21132&sc=documents It works for me. Also included is a patch if you want to build it yourself. Regards, -- Cesar |
From: djd <dj...@cm...> - 2012-05-02 00:37:35
|
Hello Cesar, > On 04/03/2012 06:15 a.m., djd wrote: > > On 4/03/2012 10:01 PM, Keith Marshall wrote: > >> 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). > > Interesting. In the case of replying to this message, the `Reply all' > > button displayed `Reply List' > > So it does know. Way back, I did not realise there was an extra reply > > button. But I know now. > > Hi djd, > I built a static regex library. Download libregex.tar.gz from: > https://skydrive.live.com/?sc=documents&cid=aa6e98f91163abaf#cid=AA6E98F91163ABAF&id=AA6E98F91163ABAF%21132&sc=documents > It works for me. Also included is a patch if you want to build it > yourself. > > Regards, > Thanks Cesar, will try it Damien |
From: Earnie B. <ea...@us...> - 2012-03-02 13:12:58
|
On Fri, Mar 2, 2012 at 4:04 AM, Eli Zaretskii <el...@gn...> wrote: >> Date: Fri, 02 Mar 2012 11:33:36 +1100 >> From: djd <dj...@cm...> > >> 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 -- Earnie -- https://sites.google.com/site/earnieboyd |
From: djd <dj...@cm...> - 2012-03-02 14:09:56
|
On 3/03/2012 12:12 AM, Earnie Boyd wrote: > On Fri, Mar 2, 2012 at 4:04 AM, Eli Zaretskii<el...@gn...> wrote: >>> Date: Fri, 02 Mar 2012 11:33:36 +1100 >>> From: djd<dj...@cm...> >>> 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 Its only a `small' command line application which I might use intensely 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 |
From: Eli Z. <el...@gn...> - 2012-03-03 07:12:56
|
> Date: Sat, 03 Mar 2012 10:44:03 +1100 > From: djd <dj...@cm...> > CC: MinGW Users List <min...@li...> > > On 3/03/2012 2:15 AM, Eli Zaretskii wrote: > >> Date: Sat, 03 Mar 2012 00:56:13 +1100 > >> From: djd<dj...@cm...> > >> > >> 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? |
From: djd <dj...@cm...> - 2012-03-03 08:07:27
|
On 3/03/2012 6:12 PM, Eli Zaretskii wrote: >> Date: Sat, 03 Mar 2012 10:44:03 +1100 >> From: djd<dj...@cm...> >> CC: MinGW Users List<min...@li...> >> >> On 3/03/2012 2:15 AM, Eli Zaretskii wrote: >>>> Date: Sat, 03 Mar 2012 00:56:13 +1100 >>>> From: djd<dj...@cm...> >>>> >>>> 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. A libintl.a came with the mingw distribution, as below: 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 |
From: Eli Z. <el...@gn...> - 2012-03-03 08:17:23
|
> Date: Sat, 03 Mar 2012 19:07:13 +1100 > From: djd <dj...@cm...> > CC: min...@li... > > 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.) |
From: djd <dj...@cm...> - 2012-03-03 11:37:10
|
On 3/03/2012 7:17 PM, Eli Zaretskii wrote: >> Date: Sat, 03 Mar 2012 19:07:13 +1100 >> From: djd<dj...@cm...> >> CC: min...@li... >> >> 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.) > Strange that libiconv only show up when -static is used. They must also 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 |
From: Eli Z. <el...@gn...> - 2012-03-03 13:11:23
|
> Date: Sat, 03 Mar 2012 22:36:56 +1100 > From: djd <dj...@cm...> > CC: min...@li... > > > 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? > 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.) |
From: djd <dj...@cm...> - 2012-03-03 13:32:41
|
On 4/03/2012 12:11 AM, Eli Zaretskii wrote: >> Date: Sat, 03 Mar 2012 22:36:56 +1100 >> From: djd<dj...@cm...> >> CC: min...@li... >> >>> 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 |