Just throwing in my tuppence.
Before I go on, let me remind everyone, this mailing list is not for dealing with MSYS based problems. MSYS
is not Mingw, but it can use the Mingw development tools. In other words, MSYS can "use" Mingw or any gcc that
the developer might have a notion to use, it is not Mingw. Mingw, out of the distro box, does not support automake or
./config. Nor was it ever designed to use automake or ./config. Mingw is designed to be used through either
cmd.exe or command.exe (DOS Console under Win32). MSYS provides a unix-like shell, which allows the
developer to build using automake and/or ./config processing through an rxvt interface.
If you have any questions about MSYS, then those should be directed to the mingw-msys m/l. Not this one.
Besides, you are more likely to get a valid and authoratative response to these sorts of questions if you post
them to the appropriate mailing list (mingw-msys@...) then you are if you post such questions to
the mingw-users list.
On 29 Mar 2002 at 18:34, Jean le Roux wrote:
> I solved the problem, but in a roundabout way.
> Here's what I did, please suggest better aproaches if you have any.
> > When I compile I get:
> > 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' c++
> > -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -c main.cc c++
> > -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -c common.cc /bin/sh
> > ../libtool --mode=link c++ -g -O2 -o isep-config.exe main.o
> > common.o -lcrypto ../libtool: cygpath: command not found c++ -g -O2
> > -o isep-config.exe main.o common.o -lcrypto common.o: In function
> > `verify_own_mac(mac_t)':
> > //e/projects/multicast/isep/confsrc/common.cc:334: undefined
> > reference to `Netbios@...' common.o: In function `get_own_mac(mac_t &,
> > int)': //e/projects/multicast/isep/confsrc/common.cc:364: undefined
> > reference to `Netbios@...'
> > //e/projects/multicast/isep/confsrc/common.cc:393: undefined
> > reference to `Netbios@...' make: *** [isep-config.exe] Error 1
> > I include windows.h. I saw it includes nb30.h, but for surety's sake
> > I included nb30.h explicitely aswell.
> The problem is not with the include.. the compiler would have caught
> "implicite declaration" of Netbios() in such a case. I realised this
> after some reflection and considderation as to _where_ the compilation
> goes wrong.
> The problem is, however, with libnetapi32.a. It's not being linked in.
> I use the same configure.in and Makefile.am for compiling my projects
> in RH Linux 7.1 and Windoze NT. Under Linux the link line will only
> need -lcrypto, under windows it needs -lcrypto and -lnetapi32, due to
> the extra use of nb30.h.
> Now, as of yet I know no clean cut way (or even a dirty one) of
> splitting my Makefile.am and/or configure.in to do different things
> under windows and linux. I can't go add -lnetapi32 to my Makefile.am's
> isep_config_LDADD = -lcrypto .. this would cause the linux build to
> Does anyone know how to test for windows and split functionality in a
> Makefile.am ?
Have you thought about asking, somewhere in your make process, which OS you are actually building for?
Mingw knows. Linux probably has no way to truly know unless you want to play with cross-compiling. It is appearing
that you are dangerously close to cross-compiling problems (which really are not the focus of this mailing list except
where existing cross-compiling hybrids, which use Mingw, are concerned. MSYS does not fall under this category.).
MSYS is MSYS, I must restate. MSYS has some oddities to it that can not be reproduced using the dos
console under Win32 because MSYS actually invokes a "shell" which is neither cmd.com or command.com, even
though the "shell" invoked is launched from a dos console. That "shell" is not the command console (win95 or other
Windows). The initiation of that shell is something you can fiddle with if you want, though I wouldn't suggest it unless
you are ready for lots of headaches.
Finally, take a look at the system variables you have available for the platform you are building for. Some of
those system variables tell make scripts which OS is actually running. To cut another cookie, automake and (g)make
are not the same thing.