hostapd cvs 07-12-2004 Broken??
Tue Dec 7 08:39:10 PST 2004
Hey Jouni & Gunter
Thanks both for replying
> > In order to build hostapd it must now link against WPA supplicant??
> No, but it needs files from ../wpa_supplicant directory. In the released
> versions, these are included in the tarball. In the CVS version, you
> just need to have full CVS checked out.
It may help if I explain what I am doing a little bit.
I get the CVS repository then use the build_gpl_release script to create
tarballs which I locate in an external source directory.
My makefile then extracts tarballs based on a version revision that I
want for a particular version of source.
Out of the hostap tarballs, I use hostap-driver and hostapd. Normally
both at CVS<date> versions.
I dont use wpa_supplicant, as Im only functioning as an AP. I also use
madwifi source in the same manner.Sometimes I use hostapd with madwifi
It seems a little bit odd. That in order to compile hostapd I must have
wpa_supplicant source installed, for the inclusion of a single file.
In my mind this seems to be going back in history from when hostap first
started out as one big tar ball. Before the individual components.
hostapd, hostap-driver, wpa-supplicant. etc where split into the
The offending bit of code in the hostapd Makefile is
# Shared TLS functions (needed for EAP_TLS, EAP_PEAP, and EAP_TTLS)
CFLAGS += -DEAP_TLS_FUNCS
OBJS += eap_tls_common.o $(DIR_WPA_SUPPLICANT)/tls_openssl.o
LIBS += -lssl -lcrypto
LIBS_p += -lcrypto
OBJS += $(DIR_WPA_SUPPLICANT)/tls_none.o
I appreciate that only having one copy of file in cvs is ideal for
updating and controlling the source. But breaking the clean linkages
between the and enforcing a requirement that hostapd requires
wpa_supplicant to compile is not good.
Will the inclusion of the required file (i.e one) be a permanent thing?
Alternativly adding this files which serves more than one package
hostap-utils would seem a more sensible option ??
Maybe this could be a good call for a hostap-lib ??
More information about the Hostap