From: Jean le R. <je...@in...> - 2002-04-12 10:29:31
|
Hi all I've added Earnies config.site script and reconfigured my project. I still dont get dll's though. the linker complains that I have undefined symbols and my -no-undefined forces libtool not to build the shared libs. While conceptually I hae no problem with this.. I cannot figure out _which_ symbols are undefined. There are no undefined symbols in my code, so i suspect it might by a -lwhatever ommision. any words of advice on how to discover what is "undefined"? Cheers -- Jean le Roux Binary Entropy Catalyst |
From: Earnie B. <ear...@ya...> - 2002-04-15 10:50:04
|
Jean le Roux wrote: > > Hi all > > I've added Earnies config.site script and reconfigured my project. I > still dont get dll's though. the linker complains that I have > undefined symbols and my -no-undefined forces libtool not to build > the shared libs. While conceptually I hae no problem with this.. I > cannot figure out _which_ symbols are undefined. There are no > undefined symbols in my code, so i suspect it might by a -lwhatever > ommision. > > any words of advice on how to discover what is "undefined"? > Your results in a different package are going to vary due to different versions of autotools and different methods for configure.in/Makefile.[am|in]. You may wish to take a look at the autoconfiguration for mhash-0.8.14 since it had good results at building a dll when libtool was properly configured. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Jean le R. <je...@in...> - 2002-04-15 13:12:11
|
On Mon, Apr 15, 2002 at 06:48:09AM -0400, Earnie Boyd wrote: > > Your results in a different package are going to vary due to different > versions of autotools and different methods for > configure.in/Makefile.[am|in]. You may wish to take a look at the > autoconfiguration for mhash-0.8.14 since it had good results at building > a dll when libtool was properly configured. I did just that (with 0.8.13). It built fine, producing both the static and shared libs. I figure the problem must be with either my auto* setup or my code. I've opted to resolve for the latter possiblilty first. So I created a small little "hello_world" project, based on the auto* setup for my bigger one. No luck though :( After a couple of test ./configure and make's I figured out that the undefined sybols come into play when I link against other libs. I initially had: #include <stdio.h> int hello_world(void) { printf("hello world\n"); return(0); } Which built fine and turned out a dll. However, if I changed my source to: #include <stdio.h> #include <iostream.h> { printf("hello world\n"); cout << "and goodbye the c++ way" << endl; return(0); } and added 'libdlltest_la_LIBADD = -lstdc++' to my Makefile.am.. the dll did _not_ build. Is there a way to FORCE libtool to link all the libs statically and not care about undefined symbols? Why is this happening in the first place? Do I need to link against more/other libs? -- Jean le Roux Binary Entropy Catalyst |
From: Jean le R. <je...@in...> - 2002-04-15 13:32:56
|
> and added 'libdlltest_la_LIBADD = -lstdc++' to my Makefile.am.. the > dll did _not_ build. > Oh, btw, this is not _just_ for libstdc++, but also if I link against libnetapi32. |
From: Earnie B. <ear...@ya...> - 2002-04-15 15:26:02
|
Jean le Roux wrote: > > > and added 'libdlltest_la_LIBADD = -lstdc++' to my Makefile.am.. the > > dll did _not_ build. > > > > Oh, btw, this is not _just_ for libstdc++, but also if I link against > libnetapi32. > Hmm... Robert Collins has posts in both cy...@cy... and cyg...@cy... about c++ not doing the right thing w.r.t. building dll's. I could be both a specs file problem as well as an libtool problem. I'd appreciate someone summarizing the problem in the MinGW lists. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Jean le R. <je...@in...> - 2002-04-15 16:11:42
|
On Mon, Apr 15, 2002 at 11:24:10AM -0400, Earnie Boyd wrote: > Jean le Roux wrote: > > > > > and added 'libdlltest_la_LIBADD = -lstdc++' to my Makefile.am.. the > > > dll did _not_ build. > > > > > > > Oh, btw, this is not _just_ for libstdc++, but also if I link against > > libnetapi32. > > > > Hmm... Robert Collins has posts in both cy...@cy... and > cyg...@cy... about c++ not doing the right thing w.r.t. > building dll's. I could be both a specs file problem as well as an > libtool problem. I'd appreciate someone summarizing the problem in the > MinGW lists. I'm compiling a condensed version atm for us. -- Jean le Roux Binary Entropy Catalyst Cellular: 083 505 6443 Inside, I'm already SOBBING! |
From: Jean le R. <je...@in...> - 2002-04-15 16:37:51
|
On Mon, Apr 15, 2002 at 06:16:46PM +0200, Jean le Roux wrote: > > I'm compiling a condensed version atm for us. So far the most promising lead is at http://sources.redhat.com/ml/cygwin/2002-04/msg00362.html For my small test project, this seems to have done the trick: in the config section of libtool, change the allow_undefined_flag="unsupported" to allow_undefined_flag="no" Perhaps you know the proper way to insert this into config.site, Earnie ? (btw, where can I find an index for the values you use in config.site ?) HTH (for now. I'll keep on looking into this with my complete project and let you know how it goes.) -- Jean le Roux Binary Entropy Catalyst |
From: Earnie B. <ear...@ya...> - 2002-04-15 17:00:55
|
Jean le Roux wrote: > > On Mon, Apr 15, 2002 at 06:16:46PM +0200, Jean le Roux wrote: > > > > I'm compiling a condensed version atm for us. > > So far the most promising lead is at > http://sources.redhat.com/ml/cygwin/2002-04/msg00362.html > > For my small test project, this seems to have done the trick: > in the config section of libtool, change the > allow_undefined_flag="unsupported" to > allow_undefined_flag="no" > Good. The values in config.site will only help if the configure functions use it. You can identify those variables because they have a _cv_ in the name. For this particular variable, it isn't cached so a patch to libtool for the mingw* host_os would need to be created. > Perhaps you know the proper way to insert this into config.site, > Earnie ? (btw, where can I find an index for the values you use in > config.site ?) > I got lucky. I had a broken msys-1.0.dll that allowed the configure script to produce the correct results. Those are the values derived from that configure script and stored in config.cache which I had to specify in order to keep. You'll have to look at the .m4 code from the libtool package to determine how each value actually get's set. You could perhaps just look at the resultant configure script. > HTH (for now. I'll keep on looking into this with my complete project > and let you know how it goes.) Yes, it helps. Keep up the good work. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Jean le R. <je...@in...> - 2002-04-16 11:06:41
|
On Mon, Apr 15, 2002 at 06:42:54PM +0200, Jean le Roux wrote: > On Mon, Apr 15, 2002 at 06:16:46PM +0200, Jean le Roux wrote: > > > > I'm compiling a condensed version atm for us. > > So far the most promising lead is at > http://sources.redhat.com/ml/cygwin/2002-04/msg00362.html > > For my small test project, this seems to have done the trick: > in the config section of libtool, change the > allow_undefined_flag="unsupported" to > allow_undefined_flag="no" > Hmmm, it seems I have new pain :(. I configure with the config.site that Earnie provided, then I fix the libtool script with the above mentioned value. When I make, everything seems to go fine. Right up to the point where it wants to link the final dll. here is the output of my make (trimmed) make all-recursive make[1]: Entering directory `/e/projects/multicast/isep' Making all in libsrc make[2]: Entering directory `/e/projects/multicast/isep/libsrc' makefile:165: warning: overriding commands for target `.s.o' makefile:162: warning: ignoring old commands for target `.s.o' makefile:182: warning: overriding commands for target `.s.lo' makefile:179: warning: ignoring old commands for target `.s.lo' /bin/sh ../libtool --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -c common.cc mkdir .libs c++ -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wp,-MD,.deps/common.pp -c common.cc -DDLL_EXPORT -DPIC -o .libs/common.lo c++ -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wp,-MD,.deps/common.pp -c common.cc -o common.o >/dev/null 2>&1 mv -f .libs/common.lo common.lo ... <snip, just a few more .o files> ... /bin/sh ../libtool --mode=link c++ -g -O2 -o libisep.la -rpath /usr/local/lib -version-info 0:0:0 common.lo isep_log.lo crypto.lo mckey.lo isep.lo -lcrypto -lstdc++ -lnetapi32 rm -fr .libs/libisep.la .libs/libisep.* .libs/libisep.* *** Warning: This library needs some functionality provided by -lcrypto. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lstdc++. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lnetapi32. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. generating symbol list for `libisep.la' dlltool --export-all --exclude-symbols DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12,DllMainCRTStartup@12,DllEntryPoint@12 --output-def .libs/libisep-0.dll-def common.lo isep_log.lo crypto.lo mckey.lo isep.lo sed -e "1,/EXPORTS/d" -e "s/ @ [0-9]*//" -e "s/ *;.*$//" < .libs/libisep-0.dll-def > .libs/libisep.exp if test "x`head -1 .libs/libisep.exp`" = xEXPORTS; then cp .libs/libisep.exp .libs/libisep-0.dll-def; else echo EXPORTS > .libs/libisep-0.dll-def; _lt_hint=1; cat .libs/libisep.exp | while read symbol; do set dummy $symbol; case $# in 2) echo " $2 @ $_lt_hint ; " >> .libs/libisep-0.dll-def;; *) echo " $2 @ $_lt_hint $3 ; " >> .libs/libisep-0.dll-def;; esac; _lt_hint=`expr 1 + $_lt_hint`; done; fi gcc -Wl,--base-file,.libs/libisep-0.dll-base -mdll -Wl,-e,_DllMainCRTStartup@12 -o .libs/libisep-0.dll common.lo isep_log.lo crypto.lo mckey.lo isep.lo common.lo: In function `generate_regkey(basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> >, basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> >, unsigned int)': //e/projects/multicast/isep/libsrc/common.cc:782: undefined reference to `SHA1' common.lo: In function `basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> >::replace(unsigned int, unsigned int, basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> > const &, unsigned int, unsigned int)': //c/msys/1.0/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../include/g++-3/std/bastring.cc(.text$_S_oom_malloc__t23__malloc_alloc_template1i0Ui+0x1e): undefined reference to `cerr' //c/msys/1.0/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../include/g++-3/std/bastring.cc(.text$_S_oom_malloc__t23__malloc_alloc_template1i0Ui+0x23): undefined reference to `ostream::operator<<(char const *)' common.lo: In function `print_pmfp_tsi_t(pmfp_tsi_t const &)': ... <snip, about 2 pages worth of similar complaints> ... //e/projects/multicast/isep/libsrc/crypto.cc:388: undefined reference to `cerr' //e/projects/multicast/isep/libsrc/crypto.cc:388: undefined reference to `ostream & operator<<<int>(ostream &, smanip<int> const &)' //e/projects/multicast/isep/libsrc/crypto.cc:388: undefined reference to `ostream::operator<<(char const *)' //e/projects/multicast/isep/libsrc/crypto.cc:388: undefined reference to `ostream & operator<<<int>(ostream &, smanip<int> const &)' //e/projects/multicast/isep/libsrc/crypto.cc:388: undefined reference to `ostream::operator<<(int)' //e/projects/multicast/isep/libsrc/crypto.cc:388: undefined reference to `ostream::operator<<(char const *)' //e/projects/multicast/isep/libsrc/crypto.cc:388: undefined reference to `ostream::operator<<(char const *)' crypto.lo: In function `crypto_t::deconstruct_advertisement_supplement(pmfp_buffer_t &, pmfp_buffer_t &)': //c/msys/1.0/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../include/g++-3/iostream.h:106: undefined reference to `endl(ostream &)' crypto.lo: In function `crypto_t::encrypt_value(pmfp_buffer_t const &, pmfp_buffer_t &, pmfp_ubuffer_t const &)': //e/projects/multicast/isep/libsrc/crypto.cc:620: undefined reference to `BF_set_key' //e/projects/multicast/isep/libsrc/crypto.cc:621: undefined reference to `BF_cfb64_encrypt' crypto.lo: In function `crypto_t::decrypt_value(pmfp_buffer_t const &, pmfp_buffer_t &, pmfp_ubuffer_t const &)': //e/projects/multicast/isep/libsrc/crypto.cc:652: undefined reference to `BF_set_key' //e/projects/multicast/isep/libsrc/crypto.cc:653: undefined reference to `BF_cfb64_encrypt' crypto.lo: In function `crypto_t::hash_value(pmfp_buffer_t const &, pmfp_buffer_t &)': //e/projects/multicast/isep/libsrc/crypto.cc:716: undefined reference to `SHA1' crypto.lo: In function `$_t6vector2Z8regkey_tZt9allocator1Z8regkey_t': //c/msys/1.0/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../include/g++-3/std/bastring.cc(.text$__ls__H3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0_R7ostreamRCt12basic_string3ZX01ZX11ZX21_R7ostream+0x16): undefined reference to `ostream::write(char const *, int)' isep.lo: In function `log_to_file(basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> >)': //e/projects/multicast/isep/libsrc/isep.cc:346: undefined reference to `cout' make[2]: *** [libisep.la] Error 1 make[2]: Leaving directory `/e/projects/multicast/isep/libsrc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/e/projects/multicast/isep' make: *** [all-recursive-am] Error 2 Why are the statndard stuff suddenly a problem? Surely linking agains libstdc++, libcrypto and libnetapi32, should resolve all the dependencies I see listed here. It appears no libs are linked in. Here is the appropriate line in my Makefile.am libisep_la_LIBADD = -lcrypto -lstdc++ -lnetapi32 Any advice gues? -- Jean le Roux Binary Entropy Catalyst |
From: Paul G. <pga...@at...> - 2002-04-17 02:02:52
|
On 16 Apr 2002 at 13:11, Jean le Roux wrote: > On Mon, Apr 15, 2002 at 06:42:54PM +0200, Jean le Roux wrote: > > On Mon, Apr 15, 2002 at 06:16:46PM +0200, Jean le Roux wrote: > > > > > > I'm compiling a condensed version atm for us. > > > > So far the most promising lead is at > > http://sources.redhat.com/ml/cygwin/2002-04/msg00362.html > > > > For my small test project, this seems to have done the trick: > > in the config section of libtool, change the > > allow_undefined_flag="unsupported" to > > allow_undefined_flag="no" > > > > Hmmm, it seems I have new pain :(. I configure with the config.site > that Earnie provided, then I fix the libtool script with the above > mentioned value. When I make, everything seems to go fine. Right up to > the point where it wants to link the final dll. > [major snippage] > Why are the statndard stuff suddenly a problem? Surely linking agains > libstdc++, libcrypto and libnetapi32, should resolve all the > dependencies I see listed here. It appears no libs are linked in. Here > is the appropriate line in my Makefile.am > > libisep_la_LIBADD = -lcrypto -lstdc++ -lnetapi32 > > Any advice gues? A guess: libtool is looking for .so files and can't find them. (libstdc++.so, libcrypto.so, etc.) Can't recall if you are using libtool binary from cygwin or not, or if you are porting libtool from scratch for MSYS. Paul G. |
From: Paul G. <pga...@at...> - 2002-04-17 23:58:53
|
On 17 Apr 2002 at 10:36, Jean le Roux wrote: > On Tue, Apr 16, 2002 at 07:01:23PM -0700, Paul G. wrote: > > A guess: libtool is looking for .so files and can't find them. > > (libstdc++.so, libcrypto.so, etc.) [On the target platform] [snip] > Not sure I quite follow your train of thought, but here goes :) > > I bootstrap my project with > ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18 > under Redhat7.1. The bootstrap includes a 'libtoolize' on my > project. This means that the libltdl dir is added to the project, and > that the libtool script is built on the target box, at configure time. > I suppose this will count as a 'port from source'. Looks like it. Thanks for clarifying. Please, bear with me as I make an attempt to get up to speed here. When you say "project" in the above context, are you referring to the project on your box, or the project on the target box? Not sure if it matters, but feel I am tracking something, but can't quite put my finger on it. At least not yet. I am thinking that you may need to actually reproduce (cross-compile, etc.) the necessary utilities under MSYS (shell or otherwise) before you will be able to bootstrap the target box (assuming your target box is MSYS), whatever that box may be. Now, the title of this thread is "problem compiling dll's". From that standpoint, there are utiltities available (either from Cygwin distro or Mingw-1.1 distro) that allow you to generate .dlls with relative ease. I am thinking that you are already aware of those utilities. The utilities, just to get it out of the way, if run separately are, gcc/g++ -c (to generate object code), and dlltool [options] (to convert object code into .dll format). These specific utilities to generate .dlls are only available within something which supports a Win32api environment since, afaik, they depend on the existence of the Win32api in order to generate the requested .dlls. The MSYS development environment is capable of invoking those utilities. Here is where things get kind of foggy for me. At bootstrap time, are you wanting to convert a particular set of (existing) libs on your (RH) box to .dll libs for the target MSYS box or are you wanting to "enable" the ability to link/generate/load .dlls on the MSYS target box? Initially, it sounds like to me is that you are wanting to build .dlls On your target box and, for some reason or another, are running into road-blocks when you attempt to build those .dlls. Is that correct? Thanks, Paul G. |
From: Jean le R. <je...@in...> - 2002-04-18 08:02:07
|
On Wed, Apr 17, 2002 at 04:57:26PM -0700, Paul G. wrote: > > I bootstrap my project with > > ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18 > > under Redhat7.1. The bootstrap includes a 'libtoolize' on my > > project. This means that the libltdl dir is added to the project, and > > that the libtool script is built on the target box, at configure time. > > I suppose this will count as a 'port from source'. > > Looks like it. Thanks for clarifying. Please, bear with me as I > make an attempt to get up to speed here. np :) > When you say "project" in the above context, are you referring to > the project on your box, or the project on the target box? Not > sure if it matters, but feel I am tracking something, but can't > quite put my finger on it. At least not yet. "my box" is the redhat 7.1 box, which is where the autotools are installed. The "target box" is an NT4.0 machine. So, before I compile, I got to /home/jean/projects/myproj on my linux box. I run my bootstrap script and then pop accross to my NT box. The NT box has a samba mount of the project dir under linux, so I simply point my MSys shell there and do a ./configure && make. > I am thinking that you may need to actually reproduce > (cross-compile, etc.) the necessary utilities under MSYS (shell or > otherwise) before you will be able to bootstrap the target box > (assuming your target box is MSYS), whatever that box may be. with "necessary utilities", are you refering to autotools? I dont use any other strange things. All the code is what i wrote myself, and I only link against -lcrypto, -lnetapi32 and -lstdc++. libcrypto I built from the sources I got from openssl. the package (openssl) does support mingw. > Now, the title of this thread is "problem compiling dll's". From > that standpoint, there are utiltities available (either from Cygwin > distro or Mingw-1.1 distro) that allow you to generate .dlls with > relative ease. I am thinking that you are already aware of those > utilities. Again.. some names please.. AFAIK there is ld and gcc and libtool (which, FWIU is replaced by ld). I did pop out a dll yesterday, with _all_ of the symbols exported :( Let me clarify: I have an API of 8 functions which I "export" with a extern "c" { ... } block, under linux. After playing around and reading on the cygwin list, I changed my code to replace the "extern" block with a __declspec(dllexport) under windows. This causes the _wanted_ API to be expoted un-mangled. So far so good. The problem is that every single other function in all my source files, are also exported :( How do I prevent this? > The utilities, just to get it out of the way, if run separately > are, gcc/g++ -c (to generate object code), and dlltool [options] > (to convert object code into .dll format). These specific > utilities to generate .dlls are only available within something > which supports a Win32api environment since, afaik, they depend on > the existence of the Win32api in order to generate the requested > .dlls. The MSYS development environment is capable of invoking > those utilities. Ah, ignore relevant comment up top :). I rely on libtool to behave and know about these things. After pathcing my egrep, as layid out by Earnie, Libtool seems to behave better (As far as GNU ld checks go). I still have to set allow_undefine="no" from allow_undefined="unsupported". This causes the dll to build for me, but with the issues mentioned above. > Here is where things get kind of foggy for me. At bootstrap time, > are you wanting to convert a particular set of (existing) libs on > your (RH) box to .dll libs for the target MSYS box or are you > wanting to "enable" the ability to link/generate/load .dlls on the > MSYS target box? Bootstrap == autoconfiscate, automaki-fy, libtoolize. At least in my world ;). The dll should be the final product of a successfull ./configure and make. > Initially, it sounds like to me is that you are wanting to build > .dlls On your target box and, for some reason or another, are > running into road-blocks when you attempt to build those .dlls. Is > that correct? 100% The crux of the problem has moved from "no dll created/output" to "dll seems wrong" -- Jean le Roux Binary Entropy Catalyst |
From: Paul G. <pga...@at...> - 2002-04-19 04:53:52
|
On 18 Apr 2002 at 10:06, Jean le Roux wrote: > On Wed, Apr 17, 2002 at 04:57:26PM -0700, Paul G. wrote: > > > I bootstrap my project with > > > ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18 > > > under Redhat7.1. The bootstrap includes a 'libtoolize' on my > > > project. This means that the libltdl dir is added to the project, > > > and that the libtool script is built on the target box, at > > > configure time. I suppose this will count as a 'port from source'. > > > > Looks like it. Thanks for clarifying. Please, bear with me as I > > make an attempt to get up to speed here. > > np :) thanks... > > > When you say "project" in the above context, are you referring to > > the project on your box, or the project on the target box? Not sure > > if it matters, but feel I am tracking something, but can't quite put > > my finger on it. At least not yet. > > "my box" is the redhat 7.1 box, which is where the autotools are > installed. The "target box" is an NT4.0 machine. > So, before I compile, I got to /home/jean/projects/myproj on my linux > box. I run my bootstrap script and then pop accross to my NT box. The > NT box has a samba mount of the project dir under linux, so I simply > point my MSys shell there and do a ./configure && make. Ok. > > > I am thinking that you may need to actually reproduce > > (cross-compile, etc.) the necessary utilities under MSYS (shell or > > otherwise) before you will be able to bootstrap the target box > > (assuming your target box is MSYS), whatever that box may be. > > with "necessary utilities", are you refering to autotools? I dont use > any other strange things. All the code is what i wrote myself, and I > only link against -lcrypto, -lnetapi32 and -lstdc++. libcrypto I built > from the sources I got from openssl. the package (openssl) does > support mingw. I guess I mean, what is absolutely necessary/required, at bare minimum (very minimalist), to affect the creation of a .dll file (properly formatted of course) on the NT4 box. Typically, if I am trying to generate a .dll under NT4 I will use dlltool, or one of the ld options (which allow the generation of Mingw formatted .dlls from existing object code). Without object code, of course, you will need to a .def file. > > > Now, the title of this thread is "problem compiling dll's". From > > that standpoint, there are utiltities available (either from Cygwin > > distro or Mingw-1.1 distro) that allow you to generate .dlls with > > relative ease. I am thinking that you are already aware of those > > utilities. > > Again.. some names please.. AFAIK there is ld and gcc and libtool > (which, FWIU is replaced by ld). There is also, dlltool.exe or simply "dlltool". > > I did pop out a dll yesterday, with _all_ of the symbols exported :( > Let me clarify: I have an API of 8 functions which I "export" with a > extern "c" { ... } block, under linux. After playing around and > reading on the cygwin list, I changed my code to replace the "extern" > block with a __declspec(dllexport) under windows. This causes the > _wanted_ API to be expoted un-mangled. So far so good. The problem is > that every single other function in all my source files, are also > exported :( How do I prevent this? Not sure. > > > The utilities, just to get it out of the way, if run separately > > are, gcc/g++ -c (to generate object code), and dlltool [options] (to > > convert object code into .dll format). These specific utilities to > > generate .dlls are only available within something which supports a > > Win32api environment since, afaik, they depend on the existence of > > the Win32api in order to generate the requested .dlls. The MSYS > > development environment is capable of invoking those utilities. > > Ah, ignore relevant comment up top :). I rely on libtool to behave and > know about these things. After pathcing my egrep, as layid out by > Earnie, Libtool seems to behave better (As far as GNU ld checks go). I > still have to set allow_undefine="no" from > allow_undefined="unsupported". This causes the dll to build for me, > but with the issues mentioned above. Ok. > > > Here is where things get kind of foggy for me. At bootstrap time, > > are you wanting to convert a particular set of (existing) libs on > > your (RH) box to .dll libs for the target MSYS box or are you > > wanting to "enable" the ability to link/generate/load .dlls on the > > MSYS target box? > > Bootstrap == autoconfiscate, automaki-fy, libtoolize. At least in my > world ;). The dll should be the final product of a successfull > ./configure and make. Ok. So, the goal is to generate a .dll that is properly formatted. > > > Initially, it sounds like to me is that you are wanting to build > > .dlls On your target box and, for some reason or another, are > > running into road-blocks when you attempt to build those .dlls. Is > > that correct? > > 100% > The crux of the problem has moved from "no dll created/output" to "dll > seems wrong" Ok. I am wondering if you can tell ld to not export your .dll symbols. I had once thought that you could, though I haven't worked with that in a while. Paul G. > > -- > Jean le Roux > Binary Entropy Catalyst > > _______________________________________________ > Mingw-msys mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-msys |
From: Jean le R. <je...@in...> - 2002-04-19 09:36:46
|
On Thu, Apr 18, 2002 at 09:52:33PM -0700, Paul G. wrote: > {long snip} > Typically, if I am trying to generate a .dll under NT4 I will use dlltool, or one of the ld options (which allow the > generation of Mingw formatted .dlls from existing object code). Without object code, of course, you will need to a .def > file. My mingw-gcc seems to call ld be default. Which is ok, since I have the source and therefore the object code, as you say. > > Again.. some names please.. AFAIK there is ld and gcc and libtool > > (which, FWIU is replaced by ld). > > There is also, dlltool.exe or simply "dlltool". oops. s/libtool/dlltool/ :) otherwise my sentence does not make much sense :) {another long snip} > > Bootstrap == autoconfiscate, automaki-fy, libtoolize. At least in my > > world ;). The dll should be the final product of a successfull > > ./configure and make. > > Ok. So, the goal is to generate a .dll that is properly formatted. Indeed > I am wondering if you can tell ld to not export your .dll symbols. I had once thought that you could, though I > haven't worked with that in a while. I shall play around with some options. and do a search on the cygwin list for some insights. Once I have all the parts in play, I will produce a short "howto" for building dlls. Hopefully this will become obsolete soon, when Earnie releases an autotools package. Thanx for all the help so far (to everybody). -- Jean le Roux Binary Entropy Catalyst |
From: Paul G. <pga...@at...> - 2002-04-19 22:45:39
|
On 19 Apr 2002 at 11:41, Jean le Roux wrote: > On Thu, Apr 18, 2002 at 09:52:33PM -0700, Paul G. wrote: > > > {long snip} > > > Typically, if I am trying to generate a .dll under NT4 I will use > > dlltool, or one of the ld options (which allow the generation of > > Mingw formatted .dlls from existing object code). Without object > > code, of course, you will need to a .def file. > > My mingw-gcc seems to call ld be default. Which is ok, since I have > the source and therefore the object code, as you say. > > > > Again.. some names please.. AFAIK there is ld and gcc and libtool > > > (which, FWIU is replaced by ld). > > > > There is also, dlltool.exe or simply "dlltool". > > oops. s/libtool/dlltool/ :) otherwise my sentence does not make much > sense :) Ok. > > {another long snip} > > > > Bootstrap == autoconfiscate, automaki-fy, libtoolize. At least in > > > my world ;). The dll should be the final product of a successfull > > > ./configure and make. > > > > Ok. So, the goal is to generate a .dll that is properly formatted. > > Indeed > > > I am wondering if you can tell ld to not export your .dll symbols. > > I had once thought that you could, though I haven't worked with that > > in a while. > > I shall play around with some options. and do a search on the cygwin > list for some insights. Once I have all the parts in play, I will > produce a short "howto" for building dlls. Hopefully this will become > obsolete soon, when Earnie releases an autotools package. Have you had time to take a look at the Howto build .dlls for Mingw (http://www.mingw.org/)? Much, if not all of what is talked about there is applicable to MSYS using Mingw, the only exception being that you are working directly out of a bash/rxvt prompt instead of directly out of a command.exe or cmd.exe prompt. Paul G. |
From: Earnie B. <ear...@ya...> - 2002-04-16 17:21:09
|
Jean le Roux wrote: > > Hmm, I've descided that libtool sniffs glue. > > I have more luck with a simple > $ c++ -c ${my source files} > $ c++ -o mylib.dll ${my oh files} ${needed libs} --shared > > The problem with this approach is that it exports all the symbols, > not just those you intend to have published. Anyone know how to limit > the exported symbols? > > Also, > $ c++ -c ${my source files} > $ c++ -o mylib.dll ${my oh files} ${needed libs} --dll > > seems to _want_ to work, but complains about not finding WinMain@16 > (huh ?) > > Anyone got insights to this. > Search for --auto-import and --exclude-import (IIRC) in the Cygwin lists as well as possibly the GCC and binutils lists. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |