Re: R: Building DLLs on C++ version code failed, but okay on C version code.
On 7/5/2010 2:13 AM, ke...@ca wrote: thank you all. You all are right. I got the desired dlls. Now I know I was misleaded by the statement that GCC is a collection of compilers and it automatically use a compiler according to a programming language. It does this for the frontend, not the backend. As you noticed, you're problem was on the backend (i.e. the linking). -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: R: Building DLLs on C++ version code failed, but okay on C version code.
thank you all. You all are right. I got the desired dlls. Now I know I was
misleaded by the statement that GCC is a collection of compilers and it
automatically use a compiler according to a programming language.
Marco atzeri-3 wrote:
--- Dom 4/7/10, ke...@ca ha scritto:
Hi there,
I wrote a file, hello.c. It has only one function: print a
message like
hello!.
# hello.c #
#include stdio.h
void hello() { printf( Hello.\n ) ; }
$gcc -c hello.c
$gcc -shared -o hello.dll hello.o
I successufully built it as DLL, hello.dll.
Then, I rewrote it in c++.
# hello.cpp ###
#include iostream
using namespace std ;
void hello() {cout Hello. endl ;}
Then, I used the commands above to built DLL, but it
failed. Why did it
fail?
wrong compiler ?
For C++ you need a C++ compiler
$g++ -c hello.cpp
$g++ -shared -o hello.dll hello.o
Marco
PS: this is not a cygwin issue, it is a very basic one.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--
View this message in context:
http://old.nabble.com/Building-DLLs-on-C%2B%2B-version-code-failed%2C-but-okay-on-C-version-code.-tp29068199p29073093.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Building DLLs on C++ version code failed, but okay on C version code.
Hi there,
I wrote a file, hello.c. It has only one function: print a message like
hello!.
# hello.c #
#include stdio.h
void hello() { printf( Hello.\n ) ; }
$gcc -c hello.c
$gcc -shared -o hello.dll hello.o
I successufully built it as DLL, hello.dll.
Then, I rewrote it in c++.
# hello.cpp ###
#include iostream
using namespace std ;
void hello() {cout Hello. endl ;}
Then, I used the commands above to built DLL, but it failed. Why did it
fail?
--
View this message in context:
http://old.nabble.com/Building-DLLs-on-C%2B%2B-version-code-failed%2C-but-okay-on-C-version-code.-tp29068199p29068199.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Building DLLs on C++ version code failed, but okay on C version code.
Forgot to attach error information.
hello.o:hello.cpp:(.text+0xd): undefined reference to
`std::basic_stringchar, std::char_traitschar, std::allocatorchar
::size() const'
hello.o:hello.cpp:(.text+0x60): undefined reference to
`std::basic_stringchar, std::char_traitschar, std::allocatorchar
::operator[](unsigned int) const'
hello.o:hello.cpp:(.text+0x9f): undefined reference to
`std::basic_stringchar, std::char_traitschar, std::allocatorchar
::operator[](unsigned int) const'
hello.o:hello.cpp:(.text+0xce): undefined reference to
`std::basic_stringchar, std::char_traitschar, std::allocatorchar
::operator[](unsigned int) const'
hello.o:hello.cpp:(.text+0x111): undefined reference to `std::cout'
hello.o:hello.cpp:(.text+0x116): undefined reference to
`std::basic_ostreamchar, std::char_traitschar std::operator
std::char_traitschar (std::basic_ostreamchar, std::char_traitschar
, char const*)'
hello.o:hello.cpp:(.text+0x11e): undefined reference to
`std::basic_ostreamchar, std::char_traitschar std::endlchar,
std::char_traitschar (std::basic_ostreamchar, std::char_traitschar
)'
hello.o:hello.cpp:(.text+0x126): undefined reference to
`std::basic_ostreamchar, std::char_traitschar
::operator(std::basic_ostreamchar, std::char_traitschar
(*)(std::basic_ostreamchar, std::char_traitschar ))'
hello.o:hello.cpp:(.text+0x149): undefined reference to
`std::ios_base::Init::Init()'
hello.o:hello.cpp:(.text+0x164): undefined reference to
`std::ios_base::Init::~Init()'
collect2: ld returned 1 exit status
ke...@ca wrote:
Hi there,
I wrote a file, hello.c. It has only one function: print a message like
hello!.
# hello.c #
#include stdio.h
void hello() { printf( Hello.\n ) ; }
$gcc -c hello.c
$gcc -shared -o hello.dll hello.o
I successufully built it as DLL, hello.dll.
Then, I rewrote it in c++.
# hello.cpp ###
#include iostream
using namespace std ;
void hello() {cout Hello. endl ;}
Then, I used the commands above to built DLL, but it failed. Why did it
fail?
--
View this message in context:
http://old.nabble.com/Building-DLLs-on-C%2B%2B-version-code-failed%2C-but-okay-on-C-version-code.-tp29068199p29068213.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Building DLLs on C++ version code failed, but okay on C version code.
On 2010-07-04 12:27 PM, ke...@ca wrote:
Forgot to attach error information.
hello.o:hello.cpp:(.text+0xd): undefined reference to
`std::basic_stringchar, std::char_traitschar, std::allocatorchar
::size() const'
hello.o:hello.cpp:(.text+0x60): undefined reference to
`std::basic_stringchar, std::char_traitschar, std::allocatorchar
::operator[](unsigned int) const'
hello.o:hello.cpp:(.text+0x9f): undefined reference to
`std::basic_stringchar, std::char_traitschar, std::allocatorchar
::operator[](unsigned int) const'
hello.o:hello.cpp:(.text+0xce): undefined reference to
`std::basic_stringchar, std::char_traitschar, std::allocatorchar
::operator[](unsigned int) const'
hello.o:hello.cpp:(.text+0x111): undefined reference to `std::cout'
hello.o:hello.cpp:(.text+0x116): undefined reference to
`std::basic_ostreamchar, std::char_traitscharstd::operator
std::char_traitschar (std::basic_ostreamchar, std::char_traitschar
, char const*)'
hello.o:hello.cpp:(.text+0x11e): undefined reference to
`std::basic_ostreamchar, std::char_traitscharstd::endlchar,
std::char_traitschar (std::basic_ostreamchar, std::char_traitschar
)'
hello.o:hello.cpp:(.text+0x126): undefined reference to
`std::basic_ostreamchar, std::char_traitschar
::operator(std::basic_ostreamchar, std::char_traitschar
(*)(std::basic_ostreamchar, std::char_traitschar ))'
hello.o:hello.cpp:(.text+0x149): undefined reference to
`std::ios_base::Init::Init()'
hello.o:hello.cpp:(.text+0x164): undefined reference to
`std::ios_base::Init::~Init()'
collect2: ld returned 1 exit status
ke...@ca wrote:
Hi there,
I wrote a file, hello.c. It has only one function: print a message like
hello!.
# hello.c #
#includestdio.h
void hello() { printf( Hello.\n ) ; }
$gcc -c hello.c
$gcc -shared -o hello.dll hello.o
I successufully built it as DLL, hello.dll.
Then, I rewrote it in c++.
# hello.cpp ###
#includeiostream
using namespace std ;
void hello() {cout Hello. endl ;}
Then, I used the commands above to built DLL, but it failed. Why did it
fail?
Use g++ to compile and link c++ code
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Building DLLs on C++ version code failed, but okay on C version code.
On 2010-07-04 10:24Z, ke...@ca wrote: $gcc -c hello.c $gcc -shared -o hello.dll hello.o I successufully built it as DLL, hello.dll. Here, the C runtime library is automatically linked. Then, I rewrote it in c++. [...] Then, I used the commands above to built DLL, but it failed. Why did it fail? Use 'g++' instead of 'gcc' for C++: g++ -c hello.cpp g++ -shared -o hello.dll hello.o Then the C++ standard library is automatically linked. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
R: Building DLLs on C++ version code failed, but okay on C version code.
--- Dom 4/7/10, ke...@ca ha scritto:
Hi there,
I wrote a file, hello.c. It has only one function: print a
message like
hello!.
# hello.c #
#include stdio.h
void hello() { printf( Hello.\n ) ; }
$gcc -c hello.c
$gcc -shared -o hello.dll hello.o
I successufully built it as DLL, hello.dll.
Then, I rewrote it in c++.
# hello.cpp ###
#include iostream
using namespace std ;
void hello() {cout Hello. endl ;}
Then, I used the commands above to built DLL, but it
failed. Why did it
fail?
wrong compiler ?
For C++ you need a C++ compiler
$g++ -c hello.cpp
$g++ -shared -o hello.dll hello.o
Marco
PS: this is not a cygwin issue, it is a very basic one.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: building DLLs?
On Dec 14 14:19, [EMAIL PROTECTED] wrote: Hi, When I download winsup from CVS it only builds the executables and 3 dlls. I'd need to build cygintl-8.dll and cygiconv-2.dll. How can I build them? Should I get the intl package from CVS (I tried, but it said that it doesn't exist, also when web-browsing the CVS folder, it is there) The intl subdir in CVS has nothing to do with the libintl provided as a Cygwin package. To get the libintl sources, download the gettext source package by using setup.exe. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: building DLLs?
Thanks, that works! Oszkar Corinna Vinschen [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 12/14/2007 03:44 PM Please respond to cygwin@cygwin.com To cygwin@cygwin.com cc Subject Re: building DLLs? On Dec 14 14:19, [EMAIL PROTECTED] wrote: Hi, When I download winsup from CVS it only builds the executables and 3 dlls. I'd need to build cygintl-8.dll and cygiconv-2.dll. How can I build them? Should I get the intl package from CVS (I tried, but it said that it doesn't exist, also when web-browsing the CVS folder, it is there) The intl subdir in CVS has nothing to do with the libintl provided as a Cygwin package. To get the libintl sources, download the gettext source package by using setup.exe. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
building DLLs?
Hi, When I download winsup from CVS it only builds the executables and 3 dlls. I'd need to build cygintl-8.dll and cygiconv-2.dll. How can I build them? Should I get the intl package from CVS (I tried, but it said that it doesn't exist, also when web-browsing the CVS folder, it is there) Thanks, Oszkar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Building DLLs from libs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK, I googled for this one but I didn't find a clear answer, so forgive me if this is already known to the list. I'm trying now to package some programs which include libs and includes. The preferred way AFAIK is to make three packages, foo with executables and docs, libfooABI with just the DLL, and libfoo-devel with libs and includes. The problem is, make doesn't build the dll by default. - From my googling it appears that there are two ways to make the DLL, through a mkdll.sh (which some apparently opposed) or through re-libtoolizing. Which is preferred and *exactly* how would I go about doing this? Thanks in advance! Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (MingW32) - WinPT 0.7.96 iD4DBQE/8+FzpiWmPGlmQSMRAp1nAJ4271rCYTfzQPkeFhbyKrw0NMz3fACY4p7F ip3QrmhqykecxtAfkWNGkw== =qxNI -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Building DLLs from libs
Hallo Yaakov, Am Donnerstag, 1. Januar 2004 um 09:59 schriebst du: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK, I googled for this one but I didn't find a clear answer, so forgive me if this is already known to the list. I'm trying now to package some programs which include libs and includes. The preferred way AFAIK is to make three packages, foo with executables and docs, libfooABI with just the DLL, and libfoo-devel with libs and includes. The problem is, make doesn't build the dll by default. That depends on the package. E.g. we have Berkeley DB, here it is useful to split because you may want to use older versions of the runtime because some other executables are linked against it and you may want to use the latest version to build new packages. Other packages with a stable interface don't need this yet (expat, zlib, ...). - From my googling it appears that there are two ways to make the DLL, through a mkdll.sh (which some apparently opposed) or through It is not recommended to do this if autotools are used. However it is used in some packages which are part of the distribution (exercise to the reader: which packages use this method to create DLLs?) re-libtoolizing. Which is preferred and *exactly* how would I go about doing this? Thanks in advance! If the autotools are used this is the recommended way. Which package are you trying to build? Generally I do s.th. like the following. Remove lines like these: AC_PREREQ(2.12) from configure.in Then try this command in the top source directory: $ autoreconf --install --verbose --force But there are some packages where this won't work, e.g. Bruno Haible's packages or developers who don't use all of the autotools like expat (where automake isn't used) are usually difficult to relibtoolize. Sometimes autoreconf is not able to do the job, then relibtoolizing manually may help: Optional: $ autoupdate $ aclocal (-I /possible/include/paths) $ libtoolize --copy --force $ aclocal (-I /possible/include/paths) Maybe: $ autoheader $ automake --add-missing --force $ autoconf Sometimes even this doesn't work because some 'features' in older versions of the autotools are used and these 'features' are disabled now, sometimes 'features' are used which aren't supported by the autotools at all (e.g expat uses non recursive make with only one toplevel Makefile). If you run into some specific problems, please feel free to ask the ML about it. Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Building DLLs from libs
Hallo Gerrit, replying myself Am Donnerstag, 1. Januar 2004 um 11:14 schriebst du: Hallo Yaakov, Am Donnerstag, 1. Januar 2004 um 09:59 schriebst du: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK, I googled for this one but I didn't find a clear answer, so forgive me if this is already known to the list. I'm trying now to package some programs which include libs and includes. The preferred way AFAIK is to make three packages, foo with executables and docs, libfooABI with just the DLL, and libfoo-devel with libs and includes. The problem is, make doesn't build the dll by default. That depends on the package. E.g. we have Berkeley DB, here it is useful to split because you may want to use older versions of the runtime because some other executables are linked against it and you may want to use the latest version to build new packages. Other packages with a stable interface don't need this yet (expat, zlib, ...). - From my googling it appears that there are two ways to make the DLL, through a mkdll.sh (which some apparently opposed) or through It is not recommended to do this if autotools are used. However it is used in some packages which are part of the distribution (exercise to the reader: which packages use this method to create DLLs?) re-libtoolizing. Which is preferred and *exactly* how would I go about doing this? Thanks in advance! If the autotools are used this is the recommended way. Which package are you trying to build? Generally I do s.th. like the following. Remove lines like these: AC_PREREQ(2.12) from configure.in I didn't mention one important part. Add the -no-undefined flag to the libxyz_la_LDFLAGS before running autoreconf, like in this case for libidn: $ cat libidn-0.3.5-1.patch --- libidn-0.3.5/lib/Makefile.am~ 2004-01-01 11:19:20.657687500 +0100 +++ libidn-0.3.5/lib/Makefile.am2004-01-01 11:19:20.657687500 +0100 @@ -34,7 +34,7 @@ punycode.h punycode.c \ idna.h idna.c libidn_la_LIBADD = $(LTLIBICONV) -libidn_la_LDFLAGS = -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) +libidn_la_LDFLAGS = -no-undefined -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) nfkc.c: gunibreak.h gunicomp.h gunidecomp.h Then try this command in the top source directory: $ autoreconf --install --verbose --force But there are some packages where this won't work, e.g. Bruno Haible's packages or developers who don't use all of the autotools like expat (where automake isn't used) are usually difficult to relibtoolize. Sometimes autoreconf is not able to do the job, then relibtoolizing manually may help: Optional: $ autoupdate $ aclocal (-I /possible/include/paths) $ libtoolize --copy --force $ aclocal (-I /possible/include/paths) Maybe: $ autoheader $ automake --add-missing --force $ autoconf Sometimes even this doesn't work because some 'features' in older versions of the autotools are used and these 'features' are disabled now, sometimes 'features' are used which aren't supported by the autotools at all (e.g expat uses non recursive make with only one toplevel Makefile). If you run into some specific problems, please feel free to ask the ML about it. Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Building DLLs to be loaded from Visual Basic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, Max Bowsher schrieb: | -mno-cygwin ... |usefull to use -fnative-struct (no more available/nessesary in | |^^^ ^ | | Incorrect. Still necessary if that is what you want. Now | called -mms-bitfields. thanks for the corrections. Alexander. - -- Alexander Mader [EMAIL PROTECTED] Fon: +49-30-93033-636 NILES Werkzeugmaschinen GmbHFax: +49-30-93033-603 www.niles.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+iUfJUABVlkcx7ZMRAnV0AJ9eWxCD/cBk5d/OjFkXumRDXd/ZsQCfaFhu t4h2uZbQW0wa+wSG8p1HCEM= =g3g4 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Building DLLs to be loaded from Visual Basic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, Massimiliano Mirra schrieb: | Mader, Alexander [EMAIL PROTECTED] writes: | | |- is anybody today successfully building DLLs with cygwin (not | mingw32) and loading them from Visual Basic (or other languages)? | |I have to provide DLLs for VB and do so by using Cygwin but with |-mnocygwin, which is more or less using mingw32. | | | Is that relevant to the DLL creation, i.e. do you know if a DLL built | without -mnocygwin (thus with cygwin) is still as usable? I have to | access the serial hardware on the target and I prefer to do it the | POSIX way rather than with the native API. You have to ensure the presence of cygwin.dll and all other cygwin-DLLs your own one depends on in the path, then it should work. Regards, Alexander. - -- Alexander Mader [EMAIL PROTECTED] Fon: +49-30-93033-636 NILES Werkzeugmaschinen GmbHFax: +49-30-93033-603 www.niles.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+iUicUABVlkcx7ZMRAqFYAKCBEXN35Abf8HeaElHyaO6UMRy/SQCgpglA M4SinfOUxo3Pr0MuxvqTgtM= =takS -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Building DLLs to be loaded from Visual Basic
I have been asked to write some code to be integrated in a legacy Visual Basic application. This code should be available as a DLL. I have built the i686-pc-linux - i686-pc-cygwin cross compiler and used it with success to compile a few small executables. Reading mailing list archives I found contrasting thoughts as to whether and how DLLs built with the cygwin toolchain can be loaded from applications written in other languages. Messages span over more than five years, and there are references to ``you must do this for this cygwin version, but with the next...'' so I'm finding it difficult to pull together a present picture. My questions: - is anybody today successfully building DLLs with cygwin (not mingw32) and loading them from Visual Basic (or other languages)? - is documentation about the process available? Thanks Massimiliano -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Building DLLs to be loaded from Visual Basic
Hallo, Massimiliano Mirra schrieb: My questions: - is anybody today successfully building DLLs with cygwin (not mingw32) and loading them from Visual Basic (or other languages)? I have to provide DLLs for VB and do so by using Cygwin but with -mnocygwin, which is more or less using mingw32. Anyway, I proceed this way in order to limit the library dependencies to native MS ones. - is documentation about the process available? I have no idea. But I know about some problems regading VB in connection with C _not_ with Cygwin. So, compiling with gcc-2 it is usefull to use -fnative-struct (no more available/nessesary in gcc). Because of the VB- Structure-Conventions it could be nessesary to use -fpack-struct together with dummy elements in the structure in question. The solution to problems like this I found in the MS database. Hope this helps, Alexander. -- Alexander Mader [EMAIL PROTECTED] Fon: +49-30-93033-636 NILES Werkzeugmaschinen GmbHFax: +49-30-93033-603 www.niles.de -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Building DLLs to be loaded from Visual Basic
Mader, Alexander [EMAIL PROTECTED] writes: - is anybody today successfully building DLLs with cygwin (not mingw32) and loading them from Visual Basic (or other languages)? I have to provide DLLs for VB and do so by using Cygwin but with -mnocygwin, which is more or less using mingw32. Is that relevant to the DLL creation, i.e. do you know if a DLL built without -mnocygwin (thus with cygwin) is still as usable? I have to access the serial hardware on the target and I prefer to do it the POSIX way rather than with the native API. I have no idea. But I know about some problems regading VB in connection with C _not_ with Cygwin. So, compiling with gcc-2 it is usefull to use -fnative-struct (no more available/nessesary in gcc). Because of the VB- Structure-Conventions it could be nessesary to use -fpack-struct together with dummy elements in the structure in question. Good to know, since I built gcc2. Not even the latter is necessary in gcc3.2, right? The solution to problems like this I found in the MS database. Hope this helps, It does. Thank you very much. Question to the list: is there any documentation repository (maybe in the style of http://www.emacswiki.org) to which one could contribute notes and experiences? I use to take notes anyway and it would nice if others could benefit. Massimiliano -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Building DLLs to be loaded from Visual Basic
Massimiliano Mirra wrote: Mader, Alexander [EMAIL PROTECTED] writes: - is anybody today successfully building DLLs with cygwin (not mingw32) and loading them from Visual Basic (or other languages)? I have to provide DLLs for VB and do so by using Cygwin but with -mnocygwin, which is more or less using mingw32. ^^ -mno-cygwin Is that relevant to the DLL creation, i.e. do you know if a DLL built without -mnocygwin (thus with cygwin) is still as usable? I have to access the serial hardware on the target and I prefer to do it the POSIX way rather than with the native API. I have no idea. But I know about some problems regading VB in connection with C _not_ with Cygwin. So, compiling with gcc-2 it is usefull to use -fnative-struct (no more available/nessesary in ^^^ ^ Incorrect. Still necessary if that is what you want. Now called -mms-bitfields. gcc). Because of the VB- Structure-Conventions it could be nessesary to use -fpack-struct together with dummy elements in the structure in question. Good to know, since I built gcc2. Not even the latter is necessary in gcc3.2, right? Still necessary. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
