Erstellt vor 6 Jahren

Zuletzt geändert vor 4 Jahren

#1804 assigned defect

Semantics of variables used in configure scripts may vary from package to package

Erstellt von: er13 Verantwortlicher: er13
Priorität: normal Meilenstein: freetz-future
Komponente: packages Version: devel
Stichworte: Beobachter:
Product Id: Firmware Version:

Beschreibung

The semantics of identically named variables used in configure scripts (and cached in config.cache) may vary from package to package. Caching the values of these variables in config.cache leads to unexpected build failures. Whether the build fails or not depends on the user's .config and the order the packages are built in.

Some examples:

  • Most configure scripts understands ac_cv_func_dlopen as "dlopen resides in libc" and ac_cv_lib_dl_dlopen as "dlopen resides in libdl", whereas some other scripts don't differentiate these two cases and use ac_cv_func_dlopen just as "dlopen is available". The same applies to ac_cv_func_(dlclose|dlsym|dlerror) vs. ac_cv_lib_dl_(dlclose|dlsym|dlerror).
  • The same applies to ac_cv_func_(math functions like sin, cos, ceil, isnan, etc.) vs. ac_cv_lib_m_(the same math functions).

It is even possible that the build process doesn't fail at all because the package provides a workaround for the case that the function is not available (some own implementation of it) or simply disables the functionality depending on the missing function.

Änderungshistorie (13)

comment:1 Geändert vor 6 Jahren durch er13

  • Status von new nach assigned geändert
  • Verantwortlicher auf er13 gesetzt

comment:2 Geändert vor 6 Jahren durch er13

In 8973:

  • Add values for ac_cv_func_(dlopen|dlclose|dlsym|dlerror) and for ac_cv_lib_dl_(dlopen|dlclose|dlsym|dlerror) to the global config.cache. Semantic: ac_cv_func_$function stands for "$function resides in libc", ac_cv_lib_dl_$function stands for "$function resides in libdl".
  • Fix packages using another semantic by patching their configure scripts or by making the variables "package specific".
  • refs #1804
  • fixes #1803

Trunk users are encouraged to remove all dl*-related values from their config.cache, e.g. by executing the following command: sed -i -r -e '/_dl(open|close|sym|error)/ d' config.cache

comment:3 Geändert vor 6 Jahren durch oliver

Wie kommt das? Wird das nicht durch automake automatisch erstellt? Sollten wir da Upstream nachfragen? Oder verwenden manche Pakete das falsch?

comment:4 Geändert vor 6 Jahren durch er13

Autoconf stellt ein paar Vorlagen zur Verfügung, um dem Entwickler das Schreiben von Tests zu erleichtern. Wie der Entwickler diese kombiniert ist seine Sache. Welche Semantik er in welche Variable reinlegt ist ebenso seine Sache (und wenn er sich für eine andere entscheidet ist es weder falsch noch richtig, autoconf schreibt keine Semantik vor, er hat sich für das entschieden, was aus seiner Sicht für sein Paket sinnvoll ist). Das Problem zu lösen (wenn man überhaupt von einem Problem sprechen kann) ist definitiv nicht die Aufgabe von Upstream.

Viel mehr tendiere ich mittlerweile dazu, dass wir auf das Speichern der Ergebnisse der Tests in config.cache gänzlich verzichten sollten, Performance hin oder her (openwrt hat übrigens kein config.cache). global- bzw. common-cache ist aber weiterhin sinnvoll für die Sachen, die aufgrund des Cross-Compilierens nicht ermittelt werden können.

Würden wir drauf verzichten, so würden wir viel weniger Probleme/Aufwände mit dem Thema haben:

  • all die PKG_MAKE_AC_VARIABLES_PACKAGE_SPECIFIC-Aufrufe werden überflüssig, das Rausfinden welches Paket durch welchen gecachten Wert Auswirkungen auf das andere hat werden wir uns ersparen.
  • die Situation, dass man irgendeine menuconfig Option umstellt und sich danach etwas nicht mehr übersetzen lässt, weil davor der andere Wert in der config.cache gecacht wurde, kann nicht mehr auftreten.
  • die Situation, dass sich ein Paket nur dann übersetzen lässt, wenn ein anderes vor ihm übersetzt wurde (weil dieses andere den notwendigen Wert in ENV exportiert) wird viel früher erkannt. Mit anderen Worten werden wir dadurch gezwungen, bei jedem Paket all die nötigen ENV-Werte in seiner .mk anzugeben.

Der einzige Nachteil ist eben die Performance. Wir sollten aus meiner Sicht diesen Punkt untersuchen, sprich Zeit mit Cache und ohne Cache miteinander vergleichen und wenn der Unterschied unter 10% liegt eben auf config.cache verzichten.

Any Gegenmeinungen, -argumente?

Zuletzt geändert vor 6 Jahren von er13 (vorher) (Diff)

comment:5 Geändert vor 6 Jahren durch oliver

Ich sehe das nicht anders. Wir erkaufen uns Performance-Vorteile durch viel Aufwand. Wir könnten in einem ersten Schritt eine menuconfig-Option für eine globale config.cache einführen, so dass diejenigen, die das wirklich wollen es noch einschalten können.

Blöderweise laufen die configure-Skripte mit nur einem Thread. Je mehr Cores man zur Verfügung hat, desto größer ist der Performance-Verlust. Mehrere Pakete gleichzeitig zu bauen scheint mir keine gute Lösung für dieses Problem…

comment:6 Geändert vor 6 Jahren durch er13

In 8979:

  • revise PKG_MAKE_*_VARIABLES_PACKAGE_SPECIFIC macros, in particular combine them into one making it possible to remove the other ones
  • change semantic a bit, the variable is now renamed from ac_cv_XY to $(pkg)_XY (previously it was renamed to $(pkg)XY i.e. no underscore in the middle)
  • update .mk files
  • fix inproper use of the macro in some .mk files
  • refs #1804

comment:7 Geändert vor 6 Jahren durch er13

In 9010:

  • fix bug introduced in r8979
  • refs #1804
  • fixes #1806 (please remove line containing ac_cv_func_statvfs from your config.cache after updating to this revision)

comment:8 Geändert vor 6 Jahren durch Whoopie

In 9016:

sane-backends: make func_dlopen "package specific" (refs #1804)

comment:9 Geändert vor 5 Jahren durch cuma

  • Meilenstein von freetz-1.3 nach freetz-future geändert

comment:10 Geändert vor 5 Jahren durch er13

In 9467:

openntpd:

  • don't cache and don't use cached value of ac_cv_have_decl_LLONG_MAX. LLONG_MIN and LLONG_MAX require -std=gnu99 to be added to the compiler flags which is however not done if cached value is used.
  • the actual reason is the inproper configure test which uses the same variable for "LLONG_MAX is available without -std=gnu99" and "LLONG_MAX is available with -std=gnu99".
  • refs #1374
  • refs #1804 (yet another reason not to use config.cache)

comment:11 Geändert vor 5 Jahren durch er13

In 9468:

openssh:

  • don't cache and don't use cached value of ac_cv_have_decl_LLONG_MAX to workaround the incorrect configure test (exactly the same error as that described in r9467)
  • refs #1374
  • refs #1804

comment:12 Geändert vor 4 Jahren durch er13

In 10586:

rrdtool/lynx:

  • don't cache and don't use cached values of ac_cv_func_acos, ac_cv_lib_m_acos variables
  • expected to fix/workaround build problems reported in #1922, #2115
  • refs #1922, #2115, #1804
  • refs #2072

comment:13 Geändert vor 4 Jahren durch cuma

In 10606:

[freetz-2.0] merge (refs #2072)


r10586 | er13 | 2013-05-31 00:09:55 GMT+01:00

rrdtool/lynx:

  • don't cache and don't use cached values of ac_cv_func_acos, ac_cv_lib_m_acos variables
  • expected to fix/workaround build problems reported in #1922, #2115
  • refs #1922, #2115, #1804
  • refs #2072

r10585 | cuma | 2013-05-30 23:57:36 GMT+01:00

3270v3: fix download url (refs #2072)


Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.