> gcc -lgw32c -lole32 -lm -o bin/mmc built/posix_randr.obj
> built/simpmesh.obj
> uilt/tettracing.obj built/mcx_utils.obj built/tictoc.obj built/tetray.obj "
>
> I am certain that gcc/ld had found the libgw32c.a that I placed
> under c:\MinGW\lib, but somehow, it does not link :(
It *does* l
Hi Arnaud,
Can't help you with your plea for NSIS help, sorry, but I'd like
to clarify...
> So, I have decided to download the GSL source files and recompile
> it with MYSYS ...
I presume you mean MSYS here; if not, what is MYSYS?
> / X86_64-mingw32.
Wouldn't that just produce 32-bit libra
Charles Calvert wrote:
> Since we're engaging in a little friendly pedantry...
:-)
> On 10/27/2009 6:30 AM, Keith MARSHALL wrote:
>
> [attributions added back in]
This utterly abysmal mail client, which my employer insists I use, messes
them up horrendously; sorry about t
>> I can't seem to get awk to work.
>> Here is the command line I'm trying to use:
>>
>> svn ls -R | awk "print $1"
>
> Try:
>
>svn ls -R | awk "{print $1}"
>
> The default rule must be enclosed in braces.
Actually, this is not strictly so; while your suggested remedy
is correct in
> grep.exe or ls.exe etc from mingw and djgpp (though it is not very
> stable for the binary from mingw if running from msdos shell.)
MS-DOS shell == 16-bit, single user, single tasking system; last ever
version published (in 1994), IIRC, was MS-DOS-6.22. If you are really
using an MS-DOS sh
> ls.exe from mingw binutils-2.19.1-mingw32-bin.tar.gz works
> for "ls.exe */*" from cmd.exe
Huh? There is no ls.exe within that package! ls is provided by the
coreutils; it has nothing to do with the binutils. The only version
of the coreutils provided by the MinGW Project is that specific
> If I set variable HOME to %HOMEDRIVE%%HOMEPATH% in XP's
> Environment Variables dialog, it works.
As expected; good.
> This and the TMP or TMPDIR variables should be set by the
> installer, not by the user.
No, they should not! It is the user's responsibility to
configure his own HOME env
Libin Varghese wrote, quoting me:
>> Where have you installed MinGW?
>>
>> If you normalise the above path, (i.e. resolve out the `..' components),
>> it becomes:
>>
>> g:/mingw/3.4.5/include/sys/stat.h
>
> I have my mingw installed in f:/mingw . I have to replace
> g:/mingw/3.4.5/bin/ to f:/m
Libin Varghese wrote:
> [snip numerous lines similar to...]
> g:/mingw/3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../include/sys/stat.h
>
> But the path specified here for the headers are not correct.
Where have you installed MinGW?
If you normalise the above path, (i.e. resolve out the `.
Bonno Bloksma wrote:
> I've read the previous posts in the group and I thought I had the
> correct syntax but I must be doing something wrong.
>
> -
> D:\temp\MANSYS>"c:\Program
> Files\GnuWin32\bin\grep.exe" -ir --include="*.rec" "version" .
That lo
Gurpreet Singh wrote:
> I am facing an issue in gnuwin32 make 3.81. The paths containing white
> space in vpath is not working properly. Is this a know bug? Is there
> any fix/patch released for this?
Does your own post not suggest a solution? Hint: avoid white space in
path names.
In general, s
Павел Сутырин wrote, quoting me:
>> You can get a pre-built binary package, (in which it is called
>> `mingw32-make'), here:
>
> Thank you very much, I'm already migrated at [EMAIL PROTECTED] mailing
> list, and there are interesting results:
>
> http://lists.gnu.org/archive/html/make-w32/2007-
Kees Zeelenberg wrote, quoting Павел Сутырин:
>> gmake.exe -> testApp.exe -> db_comparator.bat ->
>> ..\..\db_comparator\db_comparator.py
>> FAILS
>> ...
>
> This seems a make-w32 problem, which is better addressed to the make-w32
> mailing list http://lists.gnu.org/mailman/listinfo/make-w32
Michael Ramati wrote:
> gsl_function f;
> f.params = params;
> typedef double (*function_t)(double, void *);
> f.function = (function_t)GetProcAddress(library, name);
> s = gsl_root_fsolver_alloc(gsl_root_fsolver_brent);
>
> // SO FAR SO GOOD :-) that is, memory is OK!
>
> gsl_root_fsolver_set
Kay wrote:
> the precompiled library I downloaded are in .a format, but I really
> need the libary in .lib format so I can link from microsoft Visual
> Studio. Any suggestions how to convert?
Simply rename the file; `libfoo.a' becomes `foo.lib'. `libfoo.dll.a'
can similarly be named as `foo.l
Lennart Borgman wrote, quoting Marc Chantreux:
>> I think the lake of open source sh is a real problem so if i had more
>> time to spend for a windows shell , i would try to port dash (as
>> minimalist sh replacement, it can be easier to port than bash). If i
was
>> really skilled, i would try
>>> http://win-bash.sourceforge.net/
>> Or MSYS, from https://sourceforge.net/projects/mingw
>
> Personally I like 4NT, at http://www.jpsoft.com/4ntdes.htm
> but then again I've been using it since NT 3.51
I used to use 4DOS, from the same stable, until I discovered DJGPP.
No contest really; the s
>> my preferred KISS'ed shell would be ash; can I get it from
>> http://gnuwin32.sourceforge.net ?
>
> No. But what about
>
> http://win-bash.sourceforge.net/
Or MSYS, from https://sourceforge.net/projects/mingw
Regards,
Keith.
Wolfgang Jeltsch wrote:
> I've written a C program which uses libiconv and wanted it to
> build on Windows XP using MinGW 5.0.0. For both libiconv and
> libintl, I've downloaded the “binaries” and the “developer files”
> ZIP archives. I unpacked all four ZIP archives into one common
> directory C
Mohankumar wrote:
> I've the GNU tar utility 1.13.25 (windows).
>
> I've an archive with few backup files. Every file has its own
> absolute path (ie., C:\Progra~1\Backup\config.txt) in the tar
> archive.
>
> While extracting this tar, it will be extracted to the same location
> C:\Progra~1\Backup
> How can I run aclocal ? Where can I get a version of perl that can
> run gnuwin32's version of aclocal ?
I don't understand why you are trying to run aclocal. You *write*
`aclocal.m4' and `configure.ac' to customise `autoconf' behaviour,
then you run *autoconf* to generate a `configure' script.
Hi Mathias,
>> It doesn't seem to matter what `TERM=name' value is exported
>> from the shell -- info says they are all too dumb!
>
> I also tried this and could observe this behaviour too. My quick and
> dirty work around:
>
> I download the packages texinfo-4.2-4.tar.bz2,
> cygwin-1.5.12-1.tar.b
This problem, previously reported for version 4.6, is still
present in the shiny new 4.8 I downloaded from the GnuWin32
repository this morning.
It doesn't seem to matter what `TERM=name' value is exported
from the shell -- info says they are all too dumb!
Fortunately, the info 4.3 reader in my M
Hi Kees,
> Basically, the mingw headers are patched for inclusion of the
corresponding
> *x.h files; see also the 'installation and usage' section on
> http://gnuwin32.sourceforge.net/packages/libgw32c.htm. ...
I *really* don't like to do this. IMHO, the headers supplied with the
compiler sho
Hi Mathias,
> E.g. I cannot create a disk image with
>
> dd if=a: of=disk_image.bin bs=1k count=1440
>
> So you're right! Why not use cygwin's BASH or the MSYS shell?
And of course, the MSYS shell is also `bash', but typically called
`sh.exe', so it runs in POSIX compatibility mode. I use both
Hi Mathias,
>>> info: Terminal type 'dumb' is not smart enough to run Info.
>>>
>> This is the precise message I was referring to, in my earlier post,
>> when I said I could not run info 4.6 from cmd.exe.
>>
>> I normally use the MSYS shell, ...
>>
>> GnuWin32 does provide a termcap implementat
> info: Terminal type 'dumb' is not smart enough to run Info.
This is the precise message I was referring to, in my earlier post,
when I said I could not run info 4.6 from cmd.exe.
I normally use the MSYS shell, from
http://prdownloads.sourceforge.net/mingw/MSYS-1.0.10.exe?download,
so I have t
>From my earlier posting to the groff mailing list:
> As an aside, will info 4.8 be required to to read the info files
> generated by makeinfo 4.8? I currently use info 4.3, as supplied
> with MSYS, in conjunction with makeinfo 4.6 from GnuWin32, without
> problem -- I had problems with with the G
>>> In the CVS I've updated groff.texinfo to use texinfo 4.8 --
>>> unfortunately, it no longer works with older versions (causing an
>>> endless loop on my Linux box which finally aborts due to a
>>> segfault).
>>
>> This is bad news, for those of us building groff on MS-Windows :-(
>
> Well, it
29 matches
Mail list logo
