After some google searching, I am stuck : How to use the libgw32c package, coz' I am trying to compile expect under mingw :
Is it -DGW32 or -DGW32C to use ? since I found the 2 in my search
OK to include the header in sys/winx, but someone also stated what you must no include the header from sys/glibc, but how it is when I need sys/ioctl.h which is not located in winx ?
At last, do I need the "patched version" of the mingw win32 api, since I cannot found it anywhere ?
HELP PLEASE, I am going mad !!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When an include file is not provided by Mingw, then (and only then), should you include the corresponding header from Glibc. This can be achieved by adding -idirafter <glibc-include-directory> to the compile flags.
You don't need a patched win32api, although adapting it some way, may alleviate the task of including files from winx.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This does not work, including both from glibc and mingw leads to compilation errors. I solved this by including from glibc only, commenting the lines in includes that won't compile.
However, I get msg* functions, ctime_r, and errno declared but the symbols are not found during link.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Frnds.
this is gopi.i want this algorithm .so everything will be executed but i have one problem with src.rsp not open and one more cannot find the specified path." i gave correct path" but it is displys same error (LZO-2.01) can u send to my mail with correct execution
bye
gopi krishna
gopi__krishna@sify.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am getting just a fustrated as you are. The more I try to work with it the more I think there is some sort of disconect between the winx include files and the Mingw include files .... could there be some sort of revision dependancy?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am also attempting to use libgw32c with Mingw and whatever I do I am getting compilation or linkage errors.
I installed Mingw32 and libgw32c into 'c:\GnuWin32' which gives the following directory structure:
Mingw32/
usr/
include/
glibc/
winx/
The system headers directory is 'c:/Mingw32/usr/include'.
I have #include <glibc/argp.h> in my source but some of its dependent headers include for example #include <features.h> which is in the glibc directory but not the include directory.
Options as I see it are:
1. copy the glibc directory and its tree into the include directory, overwriting the existing headers,
2. create a C_INCLUDE_PATH environment variable.
Both of these then create errors at the link stage.
I don't like the suggestion of using the -idirafter in the makefile call to gcc, since it will prevent compilation on another machine that is not set up the same as mine.
If anyone can give some advice on how to get this running I would much appreciate it as I am currently going round in circles. I have looked through the mailing lists, forums, read the release notes, the FAQs, done general google searches and so far ... nothing.
Vince
(Oh, MinGW is the 4.1.0 complete package, libgw32 is 0.4, and I am using Win2k.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
After some google searching, I am stuck : How to use the libgw32c package, coz' I am trying to compile expect under mingw :
HELP PLEASE, I am going mad !!!
This does not work, including both from glibc and mingw leads to compilation errors. I solved this by including from glibc only, commenting the lines in includes that won't compile.
However, I get msg* functions, ctime_r, and errno declared but the symbols are not found during link.
hi
iam using LZO-2.01 algorithm
iam using window xp operating system and vb 6.0
how to build this algorithm
i got an error :command line erroD2022:cannot open 'b\src.rsp'
ERROR during build!
The system connot find the path specified
how to solve this problem
kesav_s2000@yahoo.co.in
Hello Frnds.
this is gopi.i want this algorithm .so everything will be executed but i have one problem with src.rsp not open and one more cannot find the specified path." i gave correct path" but it is displys same error (LZO-2.01) can u send to my mail with correct execution
bye
gopi krishna
gopi__krishna@sify.com
I am getting just a fustrated as you are. The more I try to work with it the more I think there is some sort of disconect between the winx include files and the Mingw include files .... could there be some sort of revision dependancy?
I am also attempting to use libgw32c with Mingw and whatever I do I am getting compilation or linkage errors.
I installed Mingw32 and libgw32c into 'c:\GnuWin32' which gives the following directory structure:
Mingw32/
usr/
include/
glibc/
winx/
The system headers directory is 'c:/Mingw32/usr/include'.
I have #include <glibc/argp.h> in my source but some of its dependent headers include for example #include <features.h> which is in the glibc directory but not the include directory.
Options as I see it are:
1. copy the glibc directory and its tree into the include directory, overwriting the existing headers,
2. create a C_INCLUDE_PATH environment variable.
Both of these then create errors at the link stage.
I don't like the suggestion of using the -idirafter in the makefile call to gcc, since it will prevent compilation on another machine that is not set up the same as mine.
If anyone can give some advice on how to get this running I would much appreciate it as I am currently going round in circles. I have looked through the mailing lists, forums, read the release notes, the FAQs, done general google searches and so far ... nothing.
Vince
(Oh, MinGW is the 4.1.0 complete package, libgw32 is 0.4, and I am using Win2k.)
With the present setup, idirafter is the only solution that works correctly.