[bugzilla-daemon@xxxxxxxxxxxxx]

Mike Frysinger changed bug 10788

What	Removed	Added
CC		vapier@gentoo.org

Comment # 5 on bug 10788 from Mike Frysinger

hmm, the generalization is fine, but i'm not sure in this particular case it
applies.  in looking at the current git, every use of AC_WIRESHARK_ADD_DASH_L
looks OK.

acinclude.m4 has 3 users, but each one does:
AC_DEFUN([AC_WIRESHARK_PCAP_CHECK], [
  ...
  AC_WIRESHARK_PUSH_FLAGS
  ...
  CPPFLAGS="$CPPFLAGS -I$pcap_dir/include"
  AC_WIRESHARK_ADD_DASH_L(LDFLAGS, $pcap_dir/lib)
  ...
  AC_WIRESHARK_POP_FLAGS
  ...
])
so the -L flag is being set to an explicit path (coming mostly from the user),
testing for a system lib, and then popped, so it won't pollute the build.

configure.ac has 5 users, but each one is directly added due to the user
passing an explicit path that they want like:
AC_ARG_WITH(ssl,
...
if test "x$withval" = "xno";  then
    want_ssl=no
elif test "x$withval" = "xyes"; then
    want_ssl=yes
elif test -d "$withval"; then
    want_ssl=yes
    AC_WIRESHARK_ADD_DASH_L(WS_LDFLAGS, ${withval}/lib)
fi
...
so the yes & no flags are correctly respected, and the explicit path option is
used only when configured that way.

do you have an exact scenario that still applies ?  i would believe there being
problems with the build over a year ago that has been fixed since ...

---

      You are receiving this mail because:

• You are watching all bug changes.