Menu
▾
▴
mingw-users
|
From: Stephen G. B. <sg...@so...> - 2012-12-30 10:36:49
|
Hi All In my Makefile I have --------------------------------------------- lnc.exe : lnc.o ld --force-exe-suffix -Llib -l/libfl.a lnc.o -o lnc.exe lnc.o: lex.yy.c gcc lex.yy.c -c -o lnc.o lex.yy.c : lnc.flex flex lnc.flex ----------------------------------------------- In a MinGW shell I see ------------------------------------------------------------ Stephen@Larry ~/FixText $ ls /lib libfl.a libfl_pic.a liby.a openssl perl5 Stephen@Larry ~/FixText $ ls -la /lib total 5 drwxr-xr-x 4 Stephen Administrators 0 Dec 21 20:21 . drwxr-xr-x 11 Stephen Administrators 0 Dec 21 20:21 .. -rw-r--r-- 1 Stephen Administrators 1010 Feb 6 2010 libfl.a -rw-r--r-- 1 Stephen Administrators 1118 Feb 6 2010 libfl_pic.a -rw-r--r-- 1 Stephen Administrators 1350 Apr 15 2010 liby.a drwxr-xr-x 3 Stephen Administrators 0 Dec 21 20:21 openssl drwxr-xr-x 5 Stephen Administrators 0 Dec 21 20:21 perl5 Stephen@Larry ~/FixText $ mount C:\DOCUME~1\Stephen\LOCALS~1\Temp on /tmp type user (binmode,noumount) C:\MinGW\msys\1.0 on /usr type user (binmode,noumount) C:\MinGW\msys\1.0 on / type user (binmode,noumount) C:\MinGW on /mingw type user (binmode) c: on /c type user (binmode,noumount) d: on /d type user (binmode,noumount) e: on /e type user (binmode,noumount) Stephen@Larry ~/FixText $ make ld --force-exe-suffix -Llib -l/libfl.a lnc.o -o lnc.exe C:\MinGW\bin\ld.exe: cannot find -lC:/MinGW/msys/1.0/libfl.a make: *** [lnc.exe] Error 1 Stephen@Larry ~/FixText $ ---------------------------------------------------------------------------------------------- What am I doing wrong? Regards Stephen |
|
From: LRN <lr...@gm...> - 2012-12-30 11:54:22
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30.12.2012 14:36, Stephen Grant Brown wrote: > > What am I doing wrong? > All kinds of things. But first: what are you trying to do, exactly? Do you want to build an MSys tool, or a W32 tool? That is, do you want it to: 1) Support *nix paths (/ root directory) 2) Support POSIX syscalls (such as fork/exec, shebangs, fcntl, select on any fd) 3) Depend on msys-1.0.dll 4) Be fragile ? If yes, then you want to build an MSys tool (or a Cygwin tool). Otherwise you want to build a W32 tool. Once you decide that, it should be easy to tell you what to do, and how to do it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ4CtkAAoJEOs4Jb6SI2CwJcsH/3BbRr+1y5T25FTMsh1RMJiL UoZInv8EtEEgM5w0hG8jCM59CWzQiwkmcOE90dYUiO/HffxqSaRnEFttz0c3e/oE 6jez7xZMtFWynoD/ImdEY9X0sU7tAveasvROyUNCNb6/nNRW3RVbn2kNyTQ7vGnK KuY6Q3GmtZPUishu7svuE/q6G8qwARARLqe/F247Uvx+/YUD3Ku7SNbJERSI6J3a uJKG10Atq1ANpMzEK6t/zuOLFgle/9H9SQrMygXZKicj4GQkxPnXcBPIK2gZTj/1 zgevEE9Jqbsgx93GRIbmhzY20+ORlvVNhYFk9quMpCwOvkWLMkVG1jzFQuDtsgo= =noYH -----END PGP SIGNATURE----- |
|
From: Stephen G. B. <sg...@so...> - 2012-12-30 21:50:53
|
Hi All, I want to write a program that runs under Microsoft Windows to take the data files from the Sword Project and convert them into Open Document Text files. I do not expect to use *nixpaths, POSIX calls, I would like to not have any extenal dll's. Stephen ----- Original Message ----- From: "LRN" <lr...@gm...> To: <min...@li...> Sent: Sunday, December 30, 2012 10:54 PM Subject: Re: [Mingw-users] Cannot find lib file > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 30.12.2012 14:36, Stephen Grant Brown wrote: >> >> What am I doing wrong? >> > > All kinds of things. But first: what are you trying to do, exactly? > Do you want to build an MSys tool, or a W32 tool? That is, do you want > it to: > 1) Support *nix paths (/ root directory) > 2) Support POSIX syscalls (such as fork/exec, shebangs, fcntl, select > on any fd) > 3) Depend on msys-1.0.dll > 4) Be fragile > ? If yes, then you want to build an MSys tool (or a Cygwin tool). > Otherwise you want to build a W32 tool. > > Once you decide that, it should be easy to tell you what to do, and > how to do it. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (MingW32) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJQ4CtkAAoJEOs4Jb6SI2CwJcsH/3BbRr+1y5T25FTMsh1RMJiL > UoZInv8EtEEgM5w0hG8jCM59CWzQiwkmcOE90dYUiO/HffxqSaRnEFttz0c3e/oE > 6jez7xZMtFWynoD/ImdEY9X0sU7tAveasvROyUNCNb6/nNRW3RVbn2kNyTQ7vGnK > KuY6Q3GmtZPUishu7svuE/q6G8qwARARLqe/F247Uvx+/YUD3Ku7SNbJERSI6J3a > uJKG10Atq1ANpMzEK6t/zuOLFgle/9H9SQrMygXZKicj4GQkxPnXcBPIK2gZTj/1 > zgevEE9Jqbsgx93GRIbmhzY20+ORlvVNhYFk9quMpCwOvkWLMkVG1jzFQuDtsgo= > =noYH > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_123012 > _______________________________________________ > MinGW-users mailing list > Min...@li... > > 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:min...@li...?subject=unsubscribe |
|
From: Peter v. K. <re...@gm...> - 2012-12-31 02:45:51
Attachments:
signature.asc
|
On Mon, 2012-12-31 at 08:50 +1100, Stephen Grant Brown wrote: > Hi All, > I want to write a program that runs under Microsoft Windows to take the data > files from the Sword Project and convert them into Open Document Text files. Couple of points, even if this risks becoming seriously off topic. 1) Top posting is rude. 2) Many (most?) modules of CrossWire's Sword Project are under copyright and not meant to be exported into other formats. CrossWire has obtained licenses to use these from the copyright holders. Often these licenses do not include the right of the user to copy and export. Have you checked this? 3) Exporting what is meant to be an internal format is a dangerous and silly thing as you risk to introduce transmission and conversion errors or compound and multiply our own errors. All module have a configuration file which indicates where the module text was obtained from. If your purpose is to create files in ODT or any other format - please obtain the texts directly from source in order to minimise the overall error rate. Peter (CrossWire volunteer) |
|
From: LRN <lr...@gm...> - 2012-12-31 00:07:31
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 30.12.2012 14:36, Stephen Grant Brown wrote:
> Hi All
>
> I want to write a program that runs under Microsoft Windows to take
> the data files from the Sword Project and convert them into Open
> Document Text files. I do not expect to use *nixpaths, POSIX calls,
> I would like to not have any extenal dll's.
>
> In my Makefile I have
>
> lnc.exe : lnc.o
>
> ld --force-exe-suffix -Llib -l/libfl.a lnc.o -o lnc.exe
When passed to the linker, the "-L<foo>" argument means "add the
directory <foo> to library search path" (in this case - add directory
"lib" to library search path).
Note that since "lib" is a relative path (no leading slash or <A-Z>:/ or
//), i'm not sure what happens to it - most likely ld will prepend
current working directory to it before adding it to the library search
path. That is, your library search path will have "~/FixText/lib" (well,
in expanded version - i don't know to what "~" expands in your
environment) in it, in addition to whatever it had before.
This is probably not what you wanted, you probably wanted -L/lib - to
add the root lib subdrectory to the search path.
Which is also bad, because /lib contains MSys static and import
libraries, so unless you're building an MSys package with special
msys-only tools (and you aren't), this is wrong.
MinGW/W32 libraries go to /mingw/lib directory, so it should have been
"-L/mingw/lib".
And that is redundant, since gcc will look in /mingw/lib by default
_anyway_.
"-l<foo>" means "link to <foo> library". Note that <foo> here is the
short library name. Short name does _NOT_ match the filename of the
library directly.
For example, you have:
/mingw/bin/libintl-8.dll ('intl' shared library, interface version 8)
/mingw/lib/libintl.a ('intl' static library)
/mingw/lib/libintl.dll.a ('intl' import library).
As long as the right directory (/mingw/lib or /mingw/bin) is in your
library search path, you link to one of these with "-lintl" linker
argument. Linker will, on its own accord, try first libintl.dll.a, then
libintl.a, and libintl-<anynumber>.dll, then maybe something else (read
the documentation, i don't remember the details).
If <foo> is an absolute path, it means that linker should use it
directly (AFAIR). In your case it is - "/libfl.a" is an absolute path.
So linker will try to link with the libfl.a file located in the root
directory ("/" is the root directory). Root directory is, evidently,
mapped to C:/MinGW/msys/1.0, and shrewd MSys will automatically
convert "/libfl.a" to "C:/MinGW/msys/1.0/libfl.a" when calling ld.
Now, since you don't want to build a MSys-dependent program, you can't
link to _anything_ in /lib/ directory. That is, to libfl.
AFAIU, this is flex library. I have no idea whether there is a W32
version of flex or not, we've always used MSys one (msys-flex
generates portable C code, not dependent on MSys). I would suggest
staring with that - deciding whether you really need a lexical
analyzer in your program, and if you do, which one to use, and see if
you can build flex on W32.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iQEcBAEBAgAGBQJQ4Nc3AAoJEOs4Jb6SI2Cws74H/iJJv19vf0H5+aPwo2QlBfyo
Y25FzsdkjC4/4upKI9O4qN+y453t7K33Hdgpj55jRws8jW73J/3q7u7a7lR7T1vl
YeduxlgQQi22/iw7fNJpQB95KQQrCYJZSmlNrIge+Ad5YOhlc3Go7wtG98kYE5Op
hLhDsbsGHaLFcW6xRW5Cc+eVyWPL2uTmP/a9i/yWlrwgVVXU/J2NAN5mNGCWXMuP
XEG/vxN9fAtrTuKYSlm+sOb6kg+UcE3FOAT0jCvVk5PFMgj0DmNWwDBVds7Y7bRD
P1AXr9BXa+gDzBrKv7ffad1fQKfhGpYJhrK8kqvUW+3ZOAIuzM7VRcqn7LaQzo0=
=Mf3J
-----END PGP SIGNATURE-----
|
|
From: Keith M. <kei...@us...> - 2012-12-31 01:29:57
|
On 31/12/12 00:07, LRN wrote:
> If <foo> is an absolute path, it means that linker should use it
> directly (AFAIR). In your case it is - "/libfl.a" is an absolute path.
> So linker will try to link with the libfl.a file located in the root
> directory ("/" is the root directory). Root directory is, evidently,
> mapped to C:/MinGW/msys/1.0, and shrewd MSys will automatically
> convert "/libfl.a" to "C:/MinGW/msys/1.0/libfl.a" when calling ld.
This is not correct. The OP specified "-l/libfl.a"; ld will interpret
this as 'search for the RELATIVE library path name "lib/libfl.a.a"', in
any of the search paths specified with -L, or the default paths.
Of course, this is not what the OP intends. Furthermore, he is also
using ld directly, which is also a VERY BAD idea; he should be using gcc
to link C code, g++ to link C++, gfortran for FORTRAN, etc., etc.,
so that he doesn't have to worry about specifying all of the requisite
standard libraries explicitly.
> Now, since you don't want to build a MSys-dependent program, you can't
> link to_anything_ in/lib/ directory. That is, to libfl.
Correct; you MUST NOT use MSYS libraries, in any non-MSYS application.
> AFAIU, this is flex library. I have no idea whether there is a W32
> version of flex or not, we've always used MSys one (msys-flex
> generates portable C code, not dependent on MSys). I would suggest
> staring with that - deciding whether you really need a lexical
> analyzer in your program, and if you do, which one to use, and see if
> you can build flex on W32.
A better question to consider is "why do I need libfl.a at all?"; (you
shouldn't, but if you cannot escape doing so -- why not? -- it is
trivial to implement a W32 native version [1], WITHOUT building flex
itself).
FWIW, I build the mingw-get distribution by cross compiling from Linux,
using the NATIVE flex on the Linux build-host to generate the pkginfo
scanner, (which is linked into mingw-get-0.dll); libfl.a is NOT linked
into the distributed binaries, because it simply isn't necessary [1].
[1] http://thread.gmane.org/gmane.comp.gnu.mingw.user/34912/focus=34945
--
Regards,
Keith.
|
|
From: Keith M. <kei...@us...> - 2012-12-31 14:13:34
|
On 31/12/12 01:29, Keith Marshall wrote: > This is not correct. The OP specified "-l/libfl.a"; ld will interpret > this as 'search for the RELATIVE library path name "lib/libfl.a.a"', Actually, to give the complete picture, as described in: http://sourceware.org/binutils/docs-2.23.1/ld/WIN32.html#WIN32 with the OP's spec, ld will search for each of the following, in turn: 1) lib/libfl.a.dll.a 2) /libfl.a.dll.a [1] 3) lib/libfl.a.a 4) /libfl.a.lib [1] 5) <prefix>/libfl.a.dll [2] 6) lib/libfl.a.dll 7) /libfl.a.dll [1] > in any of the search paths specified with -L, or the default paths. [1] Notice that these resolve as ABSOLUTE path names; thus, in these cases the library search paths will NOT be consulted, but rather the MSYS path translation, (for a default installation prefix), will map these, (somewhat as LRN has noted), to: 2) C:/MinGW/MSYS/1.0/libfl.a.dll.a 4) C:/MinGW/MSYS/1.0/libfl.a.lib 7) C:/MinGW/MSYS/1.0/libfl.a.dll [2] This case is intended specifically for CygWin, with <prefix> defined by: --dll-search-prefix=cyg so resolving to: 5) cyg/libfl.a.dll However, in default MinGW usage, --dll-search-prefix is undefined; thus <prefix> reduces to NOTHING, and case (5) becomes identical to case (7), which has the effect of promoting case (7) ahead of case (6) in the search order. Of course, none of the above alters the outcome; none of these search patterns matches the OP's intent. -- Regards, Keith. |
|
From: Stephen G. B. <sg...@so...> - 2013-01-03 07:24:25
|
Hi All
I am sorry I got into things above my level of understanding
----- Original Message -----
From: "Keith Marshall" <kei...@us...>
To: <min...@li...>
Sent: Monday, December 31, 2012 12:29 PM
Subject: Re: [Mingw-users] Cannot find lib file
> Of course, this is not what the OP intends.
All I want is the makefile so I can execute lnc.exe fom the following
lnc.flex file which is an examlpe in flex.info.
I am using the mingw32 / msys enviroment.
Stephen@Larry ~/FixText
$ less lnc.flex
int num_lines = 0, num_chars = 0;
%%
\n ++num_lines; ++num_chars;
. ++num_chars;
%%
main()
{
yylex();
printf( "# of lines = %d, # of chars = %d\n",
num_lines, num_chars );
}
lnc.flex (END)
>
>> Now, since you don't want to build a MSys-dependent program, you can't
>> link to_anything_ in/lib/ directory. That is, to libfl.
It no longer matters if it is a MSys-dependent program.
>
> Correct; you MUST NOT use MSYS libraries, in any non-MSYS application.
>
I will just use the MSYS flex.
PS I just did
-------------------------------------------------------
Stephen@Larry ~/FixText
$ mingw-get --reinstall install msys-flex
-----------------------------------------------
in a mingw shell.
I am sorry I got into things above my level of understanding
Stephen
|
|
From: Stephen G. B. <sg...@so...> - 2013-01-05 02:57:47
|
Hi Keith, > Okay, but I'd suggest that you should also want to understand why you > got it wrong, in the first instance. Why? Do you also suggest that a young person be qualified as a A grade mechanic before they are given a licence to drive a car on the road? PS I now have that program running correctly and can use it to write the program I want. Thanks for your help. Stephen |
|
From: Keith M. <kei...@us...> - 2013-01-03 20:29:36
|
On 03/01/13 07:24, Stephen Grant Brown wrote:
> All I want is the makefile so I can execute lnc.exe fom the following
> lnc.flex file which is an examlpe in flex.info.
Okay, but I'd suggest that you should also want to understand why you
got it wrong, in the first instance.
> $ less lnc.flex
> int num_lines = 0, num_chars = 0;
>
> %%
> \n ++num_lines; ++num_chars;
> . ++num_chars;
>
> %%
> main()
> {
> yylex();
> printf( "# of lines = %d, # of chars = %d\n",
> num_lines, num_chars );
> }
As written, this will require libfl.a; that could be a problem, because
I don't think we provide a mingw32 compatible version right now, and you
CANNOT use the MSYS version. This library provides only two functions:
yywrap(), (which yylex() will call when it exhausts its input stream),
and a default main(). You've already provided your own main(), within
your lnc.flex -- by convention, this should be lnc.l -- so all you need
from libfl.a is yywrap().
Now, it is intended that users should provide their own yywrap(); its
purpose is to allow you to attach a new data source to the input stream,
before returning zero, to instruct yylex() to continue scanning; (there
are other, arguably better, ways to achieve this). If you don't need
this capability, then you have three options:
1) Add '%option noyywrap', (without the quotes), to the first section of
lnc.l; (before the first '%%' section break -- as the first line should
suffice).
2) Add your own yywrap() implementation to the third section of lnc.l;
the default implementation, as provided by libfl.a, is as simple as:
int yywrap(){ return 1; }
so adding this, as the last line of lnc.l, would suffice.
3) Build your own mingw32 compatible libfl.a, and save it within your
/mingw/lib directory; the yywrap() implementation is as shown for option
(2), and main() is:
int main ()
{
while (yylex() != 0)
;
return 0;
}
Of these, my personal preference would be option (1).
Now, to correct your makefile: if you choose either option (1) or option
(2), you can simply remove all references to libfl.a, because you don't
need it at all; if you choose option (3), then you DO need libfl.a, but
you need to correct your references to it. In a previous post, I've
already explained why your current usage is wrong; the correct form of
reference is simply '-lfl' (again, without the quotes), and if you've
saved it in any non-standard path, you may also need to precede that
with a '-L /path/to/library' specification, so gcc knows where to look
for it; see http://mingw.org/wiki/IncludePathHOWTO for further details.
> I will just use the MSYS flex.
That's fine for compiling the flex code, but the caveat is that you
cannot use its accompanying libfl.a, because it isn't compatible with
the mingw32 compiler; you must either eliminate dependencies on libfl.a
from your flex sources, or you must furnish a mingw32 compatible version
of this library.
> I am sorry I got into things above my level of understanding
No need to apologise; this is how we raise our level of understanding.
--
Regards,
Keith.
|
|
From: Earnie B. <ea...@us...> - 2013-01-04 13:53:42
|
On Thu, Jan 3, 2013 at 5:18 AM, Keith Marshall wrote: > > That's fine for compiling the flex code, but the caveat is that you > cannot use its accompanying libfl.a, because it isn't compatible with > the mingw32 compiler; you must either eliminate dependencies on libfl.a > from your flex sources, or you must furnish a mingw32 compatible version > of this library. > IIRC, flex will build as a native app should the library be required. It has been years since I have tried to build it though. -- Earnie -- https://sites.google.com/site/earnieboyd |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X