Erstellt vor 5 Jahren

Zuletzt geändert vor 2 Jahren

#581 assigned enhancement

Build and use own libtool

Erstellt von: oliver Verantwortlicher:
Priorität: normal Meilenstein: freetz-future
Komponente: tools Version: devel
Beobachter: Product Id:
Firmware Version:

Beschreibung

We are often having problems with libtool and library search paths. e.g. libgmodule-2.0 linking is broken for me. Attached is a patch which provides the libtool binary. For full support we will have to update the download toolchains.

Can someone please write a macro for Freetz make/Makefile.in?

This is the way openwrt is doing it.

...
update_libtool=$(call replace,libtool,$(STAGING_DIR)/host/bin,$(CONFIGURE_PATH)/)
...

They replace libtool, ltmain.sh and libtool.m4 with symlink pointing to their own versions. They call it like this:

PKG_FIXUP:=libtool 

Anhänge (8)

replace_libtool_macros_v0.01.patch (2.5 KB) - hinzugefügt von er13 vor 5 Jahren.
1st version, doesn't contain everything implemented in openwrt (I'm not sure if everything is really needed)
glib2.log (233.8 KB) - hinzugefügt von er13 vor 5 Jahren.
libtool_fix.patch (13.0 KB) - hinzugefügt von oliver vor 5 Jahren.
expat.log (23.0 KB) - hinzugefügt von er13 vor 5 Jahren.
glib2-2.log (234.2 KB) - hinzugefügt von er13 vor 5 Jahren.
libtool (216.3 KB) - hinzugefügt von er13 vor 5 Jahren.
expat2.log (21.0 KB) - hinzugefügt von oliver vor 5 Jahren.
popt_no_autoreconf.patch (2.5 KB) - hinzugefügt von oliver vor 5 Jahren.

Alle Anhänge herunterladen als: .zip

Änderungshistorie (59)

Geändert vor 5 Jahren durch er13

1st version, doesn't contain everything implemented in openwrt (I'm not sure if everything is really needed)

comment:1 Geändert vor 5 Jahren durch er13

Tested the libtool_fix and replace_libtool_macros patches with glib2. glib2 doesn't compile. It seems files provided by libtool-host-package are still broken in some way. Log attached.

Geändert vor 5 Jahren durch er13

comment:2 Geändert vor 5 Jahren durch oliver

# Whether or not to optimize for fast installation.
fast_install=yes

# The host system.
host_alias=
host=x86_64-unknown-linux-gnu
host_os=linux-gnu

# The build system.
build_alias=
build=x86_64-unknown-linux-gnu
build_os=linux-gnu

# An echo program that does not interpret backslashes.
echo="echo"

# The archiver.
AR="ar"
AR_FLAGS="cru"

# A C compiler.
LTCC="gcc"

# LTCC compiler flags.
LTCFLAGS="-g -O2"

# A language-specific compiler.
CC="gcc"

# Is the compiler the GNU C compiler?
with_gcc=yes

# An ERE matcher.
EGREP="/bin/grep -E"

Im libtool Skript stehen die "falschen" Werte? Da muss ich nochmal schauen was da falsch läuft.

comment:3 Geändert vor 5 Jahren durch er13

(In [3982]) * PKG_FIX_LIBTOOL_LA macro: adjust also dependency_libs value

  • fixes libgmodule-2.0 linking problem, refs #581

comment:4 Antwort: Geändert vor 5 Jahren durch oliver

I decided to build libtool like ccache instead of integrating it into the download toolchain. Because there are hardcoded absolute paths in the script. With attached patch glib2 compiles for me. Please test and provide feedback. Next step would be to check if we then can remove some patches and fixups.

@er13 Thanks for the macros. Not very difficult but I didn't know where to start.

Geändert vor 5 Jahren durch oliver

comment:5 Geändert vor 5 Jahren durch oliver

  • Status von new nach accepted geändert
  • Verantwortlicher auf oliver gesetzt

comment:6 Geändert vor 5 Jahren durch oliver

(In [4005]) [test-branch]:

  • Build our own libtool and use it instead of package specific
  • Add new libtool fixup macro (by er13)
  • should fix glib2 build
  • refs #581

comment:7 Antwort: Geändert vor 5 Jahren durch oliver

There is a problem with the new REPLACE_LIBTOOL macro. The build continues on configure errors and doesn't stop anymore. Any ideas?

comment:8 als Antwort auf: ↑ 7 Geändert vor 5 Jahren durch er13

Replying to oliver:

There is a problem with the new REPLACE_LIBTOOL macro. The build continues on configure errors and doesn't stop anymore. Any ideas?

try

  $($(PKG)_CONFIGURE_OPTIONS) && \ 
  $($(PKG)_CONFIGURE_POST_CMDS)

instead of

  $($(PKG)_CONFIGURE_OPTIONS) ; \ 
  $($(PKG)_CONFIGURE_POST_CMDS)

in Makefile.in

p.s. Sorry, I have absolutely no time at the moment to test it myself

comment:9 als Antwort auf: ↑ 4 Geändert vor 5 Jahren durch er13

Not sure, whether libtool-host is intended to be used with each and every package… Tried to compile expat using replaced libtool $(call REPLACE_LIBTOOL,.,./conftools,./conftools). It unfortunately fails, log attached…

Geändert vor 5 Jahren durch er13

comment:10 Geändert vor 5 Jahren durch oliver

(In [4018]) [test-branch]:

  • libtool: Fix CC, CXX and CFLAGS (refs #581)

comment:11 Geändert vor 5 Jahren durch oliver

(In [4020]) [test-branch]:

  • Fix error with REPLACE_LIBTOOL macro (refs #581)

comment:12 Geändert vor 5 Jahren durch er13

expat-feedback: works for me after r4018

@r4020: it actually has nothing to do with REPLACE_LIBTOOL macro itself, it's the way the macro's being called… I didn't test it, but I think the same problem may occur if one of the commands specified in $($(PKG)_CONFIGURE_PRE_CMDS) fails

comment:13 Geändert vor 5 Jahren durch oliver

...--with-gnu-ld --disable-nls  --enable-shared --enable-static --with-gnu-ld && {  } )
/bin/bash: -c: line 0: syntax error near unexpected token `}'

But it doesn't work anymore if the variable is empty. What do we put into the brackets too fool this?

comment:14 Geändert vor 5 Jahren durch er13

(In [4022]) [test-branch]: another try to fix the problem addressed by r4020 (refs #581)

comment:15 Geändert vor 5 Jahren durch er13

It seems r4018 fixes expat, but breaks again glib2, log attached…

Geändert vor 5 Jahren durch er13

comment:16 Geändert vor 5 Jahren durch oliver

For me it works. glib2 build says:

mv -f .deps/gutils.Tpo .deps/gutils.Plo
/bin/bash ../libtool --tag=CC   --mode=link /home/oliver/freetz/trunk/toolchain/target/bin/mipsel-linux-uclibc-gcc  -Os -pipe -march=4kc -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall  -version-info 2000:5:2000 -export-dynamic  -export-symbols-regex "^g.*"  -o libglib-2.0.la -rpath /usr/lib garray.lo gasyncqueue.lo gatomic.lo gbacktrace.lo gbase64.lo gbookmarkfile.lo gcache.lo gchecksum.lo gcompletion.lo gconvert.lo gdataset.lo gdate.lo gdir.lo gerror.lo gfileutils.lo ghash.lo ghook.lo giochannel.lo gkeyfile.lo glist.lo gmain.lo gmappedfile.lo gmarkup.lo gmem.lo gmessages.lo gnode.lo goption.lo gpattern.lo gpoll.lo gprimes.lo gqsort.lo gqueue.lo grel.lo grand.lo gregex.lo gscanner.lo gsequence.lo gshell.lo gslice.lo gslist.lo gstdio.lo gstrfuncs.lo gstring.lo gtestutils.lo gthread.lo gthreadpool.lo gtimer.lo gtree.lo guniprop.lo gutf8.lo gunibreak.lo gunicollate.lo gunidecomp.lo gurifuncs.lo gutils.lo gprintf.lo libcharset/libcharset.la gnulib/libgnulib.la giounix.lo gspawn.lo    -L/home/oliver/freetz/trunk/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/lib -lpcre   -lintl  
libtool: link: /home/oliver/freetz/trunk/toolchain/target/bin/mipsel-linux-nm -B  .libs/garray.o .libs/gasyncqueue.o .libs/gatomic.o .libs/gbacktrace.o .libs/gbase64.o .libs/gbookmarkfile.o .libs/gcache.o .libs/gchecksum.o .libs/gcompletion.o .libs/gconvert.o .libs/gdataset.o .libs/gdate.o .libs/gdir.o .libs/gerror.o .libs/gfileutils.o .libs/ghash.o .libs/ghook.o .libs/giochannel.o .libs/gkeyfile.o .libs/glist.o .libs/gmain.o .libs/gmappedfile.o .libs/gmarkup.o .libs/gmem.o .libs/gmessages.o .libs/gnode.o .libs/goption.o .libs/gpattern.o .libs/gpoll.o .libs/gprimes.o .libs/gqsort.o .libs/gqueue.o .libs/grel.o .libs/grand.o .libs/gregex.o .libs/gscanner.o .libs/gsequence.o .libs/gshell.o .libs/gslice.o .libs/gslist.o .libs/gstdio.o .libs/gstrfuncs.o .libs/gstring.o .libs/gtestutils.o .libs/gthread.o .libs/gthreadpool.o .libs/gtimer.o .libs/gtree.o .libs/guniprop.o .libs/gutf8.o .libs/gunibreak.o .libs/gunicollate.o .libs/gunidecomp.o .libs/gurifuncs.o .libs/gutils.o .libs/gprintf.o .libs/giounix.o .libs/gspawn.o   libcharset/.libs/libcharset.a gnulib/.libs/libgnulib.a | sed -n -e 's/^.*[	 ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[	 ][	 ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | /bin/sed 's/.* //' | sort | uniq > .libs/libglib-2.0.exp

This line comes from libtool:

# Take the output of nm and produce a listing of raw symbols and C names.
global_symbol_pipe="sed -n -e 's/^.*[ <>]\\([ABCDGIRSTW][ABCDGIRSTW]*\\)[ <---->][ <--->]*\\([_A-Za-z][_A-Za-z0-9]*\\)\$/\\1 \\2 \\2/p'"

comment:17 Geändert vor 5 Jahren durch er13

Are you sure, you're testing the right version (your output contains "trunk")?

Tested it again, it definitely doesn't work for me, also after deleting config.cache (it contains lt_cv_sys_global_symbol_pipe)…

comment:18 Geändert vor 5 Jahren durch oliver

How does your global_symbol_pipe line in the libtool script look like?

comment:19 Geändert vor 5 Jahren durch er13

strangely enough my libtool contains two definitions of global_symbol_pipe in it, both are empty

Geändert vor 5 Jahren durch er13

comment:20 Geändert vor 5 Jahren durch er13

this

--- toolchain/make/target/libtool-host/libtool-host.mk	(revision 4116)
+++ toolchain/make/target/libtool-host/libtool-host.mk	(working copy)
@@ -56,7 +56,7 @@
 		install
 	$(SED) -i -r -e 's,(hardcode_into_libs)=yes,\1=no,g' $(LIBTOOL_HOST_TARGET_SCRIPT)
 
-libtool-host: $(LIBTOOL_HOST_TARGET_SCRIPT)
+libtool-host: uclibcxx $(LIBTOOL_HOST_TARGET_SCRIPT)
 
 libtool-host-source: $(LIBTOOL_HOST_DIR)/.unpacked
 

fixes (or workarounds?) the problem for me. It seems g++ is not functional without uclibc++. All g++-related tests libtool's configure script carries out fail resulting in the libtool script attached 2 weeks ago. We should probably consider installing uclibc++ together with gcc.

comment:21 Antwort: Geändert vor 5 Jahren durch oliver

I removed uclibcxx from my toolchain and removed CXX line from libtool-host.mk. But I can't see any problem?

—removed diff—

comment:22 als Antwort auf: ↑ 21 Geändert vor 5 Jahren durch er13

Replying to oliver:

I removed uclibcxx from my toolchain and removed CXX line from libtool-host.mk. But I can't see any problem?

You mean linking against libstdc++ is not a problem? Can you compile expat with the change above?

comment:23 Antwort: Geändert vor 5 Jahren durch oliver

Meanwhile uclibc++ is build again. But this doesn't matter (?) because expat doesn't need it. Attached is the build log.

Geändert vor 5 Jahren durch oliver

comment:24 als Antwort auf: ↑ 23 Geändert vor 5 Jahren durch er13

Replying to oliver:

Meanwhile uclibc++ is build again. But this doesn't matter (?) because expat doesn't need it.

Ok, expat doesn't require uclibc++, but as soon as we build some c++ library/application using replaced libtool linking against libstdc++ would be a problem. Or do you plan to include it (it's about 2.6MB big) into freetz?

comment:25 Antwort: Geändert vor 5 Jahren durch oliver

No, I don't plan to. ;-) But I tried to search why this fixes your problem. That for me hasn't obviously nothing to do with uClibc++? Sure we should build uClibc++ before libtool to get the correct CXX Tag configuration. Or we have to use sed to fix it.

comment:26 als Antwort auf: ↑ 25 Geändert vor 5 Jahren durch er13

Replying to oliver:

Sure we should build uClibc++ before libtool to get the correct CXX Tag configuration. Or we have to use set to fix it.

Would you please try the following make uclibcxx-clean libtool-host-dirclean, rm make/config.cache. Add CXX-line back into libtool-host.mk and remove uclibcxx-dependency from it, i.e. ensure libtool-host is built without uclibc++ in staging dir and with no config.cache. This way it's built now, when doing clean build. Building libtool-host this way produces corrupted libtool-script on my system (does it on yours?). The fix is, as mentioned above, to add the uclibc++ dependency.

comment:27 Antwort: Geändert vor 5 Jahren durch oliver

What do you mean with corrupt script? On which package, lib I should try?

libtool-host package doesn't use make/config.cache!?

comment:28 als Antwort auf: ↑ 27 Geändert vor 5 Jahren durch er13

Replying to oliver:

What do you mean with corrupt script? On which package, lib I should try?

Like the one i've attached two weeks ago. Building glib2 using it fails, see glib2-2.log

comment:29 Antwort: Geändert vor 5 Jahren durch oliver

Okay. I found the problem.

checking command to parse /home/oliver/fritzbox/freetz/trunk-test/toolchain/target/bin/mipsel-linux-uclibc-nm -B output from /home/oliver/fritzbox/freetz/trunk-test/toolchain/target/bin/mipsel-linux-uclibc-gcc object... failed

Here it tries to compile a code snippet with CXX.

Should we leave this "CXX=… \" line away? And use sed to replace the following lines in the installed libtool script?

-CC="mipsel-linux-uclibc-g++"  
+CC="$(TARGET_TOOLCHAIN_STAGING_DIR)/bin/mipsel-linux-uclibc-g++-uc"  

-postdeps="-lstdc++ -lm -lgcc_s -lc -lgcc_s" 
+postdeps="-luClibc++ -lc -lgcc -lgcc_s"  

But I think it's the most suitable solution to make uclibc++ a prerequisite of libtool. From the beginning I wasn't sure where to put this libtool package…

comment:30 als Antwort auf: ↑ 29 Geändert vor 5 Jahren durch er13

Replying to oliver:

But I think it's the most suitable solution to make uclibc++ a prerequisite of libtool.

agree with you… Would not it be better to build and install uclibc++ together with gcc as it actually replaces part of it?

comment:31 Geändert vor 5 Jahren durch oliver

(In [4210]) * Build uClibc++ before libtool-host

comment:32 Geändert vor 5 Jahren durch oliver

(In [4394]) * Reintegrate test branch!

  • refs #90, #562, #581
  • /usr/lib/freetz is now our libdir. All Freetz libs go there and are not "seen" by AVM binaries. TODO: What to do with duplicates? e.g. libz
  • no more libcrypto segfaults (perhaps we can external our libcrypto?)
  • hide some build output with verbose level 0 (only packages atm)
  • Please report problems in the corresponding tickets

comment:33 Geändert vor 5 Jahren durch make

Ich hab seit dem Merge von test-branch und trunk in [4394] das Problem, dass die shared libraries nicht mehr gefunden werden. Als Beispiel mal streamripper, das vor dem merge ohne Probleme lief. Nach dem Merge sieht das folgendermassen aus:

root@fritz:/var/mod/root# ldd /usr/bin/streamripper 
        libmad.so.0 => not found
        libpthread.so.0 => /lib/libpthread.so.0 (0x2aabe000)
        libogg.so.0 => not found
        libvorbis.so.0 => not found
        libm.so.0 => /lib/libm.so.0 (0x2aae2000)
        libglib-2.0.so.0 => not found
        libintl.so.8 => not found
        libpcre.so.0 => not found
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2ab0d000)
        libc.so.0 => /lib/libc.so.0 (0x2ab2b000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2aaa8000)

Auf dem Build-Host bekomme ich:

make@mini.fritz.box:~/projects/freetz-trunk$ readelf -d build/modified/filesystem/usr/lib/freetz/libmad*|grep rpath
 0x0000000f (RPATH)                      Library rpath: [/usr/lib/freetz]
 0x0000000f (RPATH)                      Library rpath: [/usr/lib/freetz]
 0x0000000f (RPATH)                      Library rpath: [/usr/lib/freetz]
make@mini.fritz.box:~/projects/freetz-trunk$ readelf -d build/modified/filesystem/usr/bin/streamripper*|grep rpath
 0x0000000f (RPATH)                      Library rpath: [/usr/lib/freetz]

(Hab gerade gesehen, dass ich das Problem auch zB bei ltrace habe. Dort kann libelf nicht geladen werden.)

Als workaround kann ich den LD_LIBRARY_PATH umsetzen…

export LD_LIBRARY_PATH=/usr/lib/freetz:$LD_LIBRARY_PATH

… aber war das so gedacht?

comment:34 Geändert vor 5 Jahren durch oliver

Du musst alle Sourcen und deine Toolchain löschen damit das wieder funktioniert. Siehe IPPF

comment:35 Geändert vor 5 Jahren durch make

Ok, ich versuchs jetzt mal mit

make@mini.fritz.box:~/projects/freetz-trunk$ rm -rf build toolchain source root
make@mini.fritz.box:~/projects/freetz-trunk$ svn up
make@mini.fritz.box:~/projects/freetz-trunk$ make

Das dirclean nicht funktioniert, hab ich daran gemerkt, dass mein image nach dem Patch plötzlich 600kb größer war, weil dirclean die alten libraries unter root/usr/lib nicht angefasst hat. Vielleicht sollte dirclean etwas weiträumiger löschen. Mir wäre das jedenfalls lieber, als ein paar Sekunden beim build nach einem dirclean zu sparen.

Vielen Dank erstmal für deinen Hinweis.

comment:36 Geändert vor 5 Jahren durch make

Und noch eine Kleinigkeit, dieses Mal libxml2. In tools/external wurde der Library-Pfad nicht angepasst, aber unter make/libs/external.in wird in der Beschreibung der neue Pfad genannt. Ich denke, da fehlt die Anpassung in tools/external. Dazu kommt gleich ein Patch von mir im Forum, da ich an libxml2 und an tools/external für die libxslt-Integration ohnehin ran muss(te).

Geändert vor 5 Jahren durch oliver

comment:37 Geändert vor 5 Jahren durch oliver

  • Lösung auf fixed gesetzt
  • Status von accepted nach closed geändert

(In [4547]) * libtool-host: Remove some unwanted lines in libtool script

  • Don't set LD_RUN_PATH. It is set by Freetz
  • closes #581

comment:38 Geändert vor 5 Jahren durch er13

  • Lösung fixed gelöscht
  • Status von closed nach reopened geändert

@Oliver: ich bin dagegen es auf die Art und Weise zu lösen, wie Du es in r4547 gelöst hast. Offensichtlich greifen die Patches bei Dir nicht (Grund: fehlende aclocal-1.10 und automake-1.10?). r4547 ist nicht anderes als den (Folge-)Fehler an einer anderen Stelle auszubügeln.

Entweder sorgen wir dafür, dass die Patches immer greifen, unabhängig davon, ob aclocal/automake in den richtigen Versionen auf dem Build-System vorhanden sind. Oder wir schmeissen die Patches raus und machen alles per sed. Sonst ist es doppelt gemoppelt…

comment:39 Geändert vor 5 Jahren durch oliver

edit: Okay, hat sich wohl erledigt…

comment:40 Geändert vor 5 Jahren durch er13

  • Lösung auf fixed gesetzt
  • Status von reopened nach closed geändert

comment:41 Geändert vor 5 Jahren durch er13

fixed in r4553

comment:42 Geändert vor 5 Jahren durch oliver

(In [4580]) * glib2: Fix libtool failure (refs #581) by er13

comment:43 Antwort: Geändert vor 5 Jahren durch er13

Wie im IPF versprochen, ein paar Gedanken laut. Um das Problem etwas besser diskutieren zu können, sei der momentane Ablauf beim Ersetzen von libtool skizziert:

1) Ersetze, sofern vorhanden, libtool, ltmain.sh und libtool.m4 in CONFIGURE_PRE_CMDS.

2) Rufe configure auf. Man beachte, dass configure in den allermeisten Fällen eine libtool-Vorlage in sich enthält und zwar entweder vollständig oder nur einen Teil davon. Ist die Vorlage nicht vollständig in configure enthalten, so enthält ltmain.sh den zweiten Teil (libtool.m4 ist nur dann notwendig, wenn man alles mittels auto*-tools neu generieren möchte). Während seines Laufs erzeugt das configure-Script aus der Vorlage das libtool-Script. Ist die Vorlage auf mehrere Dateien verteilt, so bedient es sich der bereits ersetzten ltmain.sh während der in configure enthaltene Teil noch der originale ist.

3) Ersetze, sofern vorhanden, libtool, ltmain.sh und libtool.m4 in CONFIGURE_POST_CMDS.

Bei diesem Vorgehen können wir in folgende Probleme reinlaufen:

1) Der in configure enthaltene Teil und unsere ltmain.sh sind inkompatibel → das Generieren von libtool, dass wir in Schritt 3 ersetzen, scheitert. configure bricht ab.

2) Das Generieren von libtool aus configure heraus scheitert zwar nicht, das generierte Script ist aber ein Schmarrn. Würde configure dieses nur temporär existierende libtool-Script nicht aufrufen, so würde uns das nicht stören. Im Falle von glib2 passiert es aber ganze 3 Mal. Zwei Aufrufe sind harmlos, der dritte (der aus r4580), wie sich herausgestellt hat, nicht. Auf machen Systemen scheitert er.

3) Streng genommen sind libtool-1.5.x und libtool-2.2.x nicht vollständig kompatibel. Nutzt ein Paket irgendwelche Features von 2.2.x (unser libtool ist 1.5.x), könnte das theoretisch auch zu Problemen führen.

Denkbare Lösungen (entweder oder, beide noch ungetestet):

1) libtool nur in CONFIGURE_POST_CMDS zu ersetzen. Zwei Versionen von libtool zur Verfügung zu stellen. Beim Ersetzen darauf zu achten, welche im original Paket enthalten war.

2) ich meine alle notwendigen Änderungen mittels PREVENT_RPATH_HARDCODING Macros (das dann umbenannt werden müsste) umsetzen zu können. libtool-host Paket müssen wir aber weiterhin zur Verfügung stellen, da ich schon Pakete gesehen habe, bei den das mitgelifert libtool broken ist.

p.s. und ich öffne mal das Ticket wieder.

comment:44 Geändert vor 5 Jahren durch oliver

  • Lösung fixed gelöscht
  • Status von closed nach reopened geändert

Ich hatte das ursprünglich bei openwrt gesehen. Die ersetzen libtool erst nach dem configure. Warum brauchen wir da 2 Versionen?

comment:45 Geändert vor 5 Jahren durch er13

Die bei openwrt ersetzen es sowohl vor dem configure als auch danach (s. da), ist ja auch logisch, sonst würde es keinen Sinn machen ltmain.sh und libtool.m4 zu ersetzen. Ich habe jetzt bei mir auf "nur danach ersetzen"-umgestellt und es funktioniert genauso. Grund ist aber, denke ich, dass die von mir oben skizzierten Probleme bisher nur theoretischer Natur sind, wir haben halt kein Paket, auf welches das oben zutrifft. Ich würde vorschlagen, dass wir das so lassen, wie es grade ist (d.h. ersetzen vor und danach) und es im Kopf behalten, dass wir beim Ersetzen darauf achten müssen, dass das configure während seines Lauf das libtool script nicht aufruft. Sollte irgendwann mal ein Paket auftauchen, wo das oben doch ein Problem ist, dann können wir uns überlegen, wie wir dieses lösen.

In Bezug auf 2 Versionen: libtool-1.5.x und libtool-2.2.x sind streng genommen nicht 100% kompatibel. Manche Parameter, wenn ich mich nicht irre, sind sogar syntaktisch gleich geblieben, haben aber jetzt eine andere Semantik. Daher dachte ich, wäre es besser, dass wir sowohl 1.5.x als auch 2.2.x zur Verfügung stellen und beim Ersetzen die Major-Version verwenden, die in dem original Paket enthalten war.

comment:46 als Antwort auf: ↑ 43 ; Antwort: Geändert vor 5 Jahren durch oliver

Replying to er13:

ich meine alle notwendigen Änderungen mittels PREVENT_RPATH_HARDCODING Macros (das dann umbenannt werden müsste) umsetzen zu können. libtool-host Paket müssen wir aber weiterhin zur Verfügung stellen, da ich schon Pakete gesehen habe, bei den das mitgelifert libtool broken ist.

Ich wollte durch das libtool ersetzen das PREVENT_RPATH_HARDCODING loswerden. Aber das mit libtool ersetzen ist doch nicht so einfach wie gedacht. Hast du eine Liste im Kopf welche Pakete eine kaputtes libtool haben? Dann würde ich vorschlagen nur für diese wenigen Pakete libtool zu ersetzen. Und erstmal bei libtool-1.5 bleiben bis wir wirklich ein Paket haben welches ein Problem verursacht. Und für die anderen Pakete verwenden wir das Macro.

edit: Momentan verwenden folgende Pakete das Macro: dtmfbox gd glib2 jamvm libdnet (auskommentiert) owfs

comment:47 Geändert vor 4 Jahren durch oliver

  • Status von reopened nach assigned geändert
  • Verantwortlicher oliver gelöscht

comment:48 Geändert vor 4 Jahren durch oliver

Besteht hier aktuell Handlungsbedarf oder kann das Ticket nach 1.3?

comment:49 als Antwort auf: ↑ 46 Geändert vor 4 Jahren durch er13

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

Replying to oliver:

Pakete eine kaputtes libtool haben? Dann würde ich vorschlagen nur für diese wenigen Pakete libtool zu ersetzen. Und für die anderen Pakete verwenden wir das Macro.

d'accord

Die Macro-Lösung (für das RPATH-Problem) hat für mich folgende Vorteile:

  • leichter in der Anwendung, da die Menge der zu modifizierenden / zu ersetzenden Dateien und Abhängigkeiten zwischen diesen geringer (d.h. leichter/schneller ermittelbar) ist. Hat weniger Auswirkungen. Kann sogar so ziemlich blind wie hier eingesetzt werden.
  • funktioniert auch mit Paketen, die während der configure-Phase das libtool-Script aufrufen.
  • funktioniert auch mit Host-Paketen bzw. löst Target-Probleme ohne sich auf Host auszuwirken, s. wieder gcc.mk
  • libtool's Version unabhängig.
  • bei Bedarf auch auf Pakete erweiterbar, die kein libtool verwenden.

Replying to oliver:

Besteht hier aktuell Handlungsbedarf oder kann das Ticket nach 1.3?

Für 1.2 sehe ich keinen.

Ich habe mir die Ticket-Beschreibung nochmal durchgelesen. Dabei ist mir aufgefallen, dass mir das Ziel dieses Tickets nicht ganz klar ist. RPATH-Problem ist für mich das "library search paths"-Problem auf dem Target. Das "library search paths"-Problem auf dem Host (während der Linking-Phase) ist für mich ein etwas anderes Problem. War vielleicht das Abschaffen von all den Macros, wie FIX_LIBTOOL_LA, PREVENT_RPATH, die alle nur ein Teilproblem lösen, das eigentliche Ziel?

comment:50 Geändert vor 4 Jahren durch oliver

Mir ging es nur um PREVENT_RPATH_HARDCODING. Vielleicht hab ich es in der Beschreibung durcheinander gebracht. Bei nochmaligem Lesen ist mir das auch nicht mehr ganz klar. :-)

comment:51 Geändert vor 2 Jahren durch cuma

  • Meilenstein von freetz-1.3 nach freetz-future geändert
Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.