Wie pthreadGC2 statisch in x264 kompilieren?

Selur

Wie der Titel schon sagt würde ich gerne wissen wie man x264 kompilieren muss, dass es nicht mehr von der pthreadGC2.dll abhängig ist.

Wie ich es versucht habe:

Zitat

1. Herunterladen der aktuellen pthreads sourcen:

Code

cvs -z3 -d:pserver:anoncvs@sources.redhat.com:/cvs/pthreads-win32 co -P pthreads

2. pthreads bauen:

Code

make clean GC-static

dies liefert:

Code

-f *.irm -f *.orm -f *.objrm -f *.exerm -f pthread.defmake XOPT="-DPTW32_BUILD_INLINED -DPTW32_STATIC_LIB" CLEANUP=-D__CLEANUP_C XC_FLAGS=" " OBJ="pthread.o version.o" libpthreadGC2.stampmake[1]: Entering directory `/c/programme/pthreads'gcc -c -o pthread.o -D__CLEANUP_C -O3 -finline-functions -DPTW32_BUILD_INLINED -DPTW32_STATIC_LIB -I. -DHAVE_CONFIG_H -Wall  pthread.cwindres --include-dir=. -D__CLEANUP_C -o version.o version.rcrm -f libpthreadGC2.aar -rv libpthreadGC2.a pthread.o version.oa - pthread.oa - version.oc:\programme\mingw\bin\ar.exe: creating libpthreadGC2.aranlib libpthreadGC2.aecho touched > libpthreadGC2.stampmake[1]: Leaving directory `/c/programme/pthreads'

3. .a und .h files in die MInGW Ordner kopieren:
libpthreadGC2.a in den MinGW\lib Ordner
alle *.h Dateien in den MinGW\include Ordner

4. in den x264 Ordner wechseln

5. x264 konfigurieren:

Code

configure --enable-avis-input --enable-mp4-output --enable-pthread --extra-cflags="-Ic:/programme/gpac/include" --extra-ldflags="-Lc:/programme/gpac/bin/gcc"

6. x264 bauen:

Code

make

Alles anzeigen

Leider ist die x264.exe die erstellt wird aber immer noch von der pthreadGC2 .dll abhängig.

-> Was tun?

Cu Selur

gispos

Ich mach jetzt mal nen Schuss ins Blaue!

Ist schon lange her das ich mit MinGW ffmpeg kompiliert habe, und an x264 habe ich mich noch nicht Versucht.
In deinem Configure rufst Du doch --enable-pthread auf.

Deshalb meine Frage: Läuft x264 ohne den pthread (also ohne den Aufruf) nicht?
Ist es überhaupt möglich den pthread statisch einzubinden?

Möchte Dir nur ein paar Denkanstöße geben, ohne mich mit dem x264 Code näher zu Beschäftigen kann ich da keine weitere Hilfe anbieten.

Gruß gispos

Selur

Zitat

Läuft x264 ohne den pthread (also ohne den Aufruf) nicht?

doch kann man auch ohne pthread kompilieren (ging zumindest früher)

Zitat

Ist es überhaupt möglich den pthread statisch einzubinden?

Hatte letztens eine x264 Version bei der pthreads statisch drinne war, geht also. Weiß nur nicht mehr woher die war sonst wüsste ich auch wen ich fragen müsste.

LoRd_MuldeR

Also bei meiner MinGW Installation (TDM's Experimental GCC) gibt es im "MinGW\lib" Verzeichnis gleich drei pthreads Dateien:
pthread.a, pthreadGCE2.a und libpthreadGC2-static.a

Wenn ich in der Standardkonfiguration im x264 Source-Ordner "./configure" ohne zusätzliche Parameter aufrufe, sagt er mir "pthread: yes". Wenn ich dann "make" aufrufe, bindet er die "pthreadGC2.dll" dynamisch ein. Benenne ich nun aber die "pthread.a" in "pthread.off" um und rufe wieder "./configure" auf, sagt er diesmal "pthread: no". Nun noch "libpthreadGC2-static.a" in "libpthreadGC2.a" umbenennen und "./configure" gibt erneut "pthread: yes" aus. Wenn ich jetzt "make" ausführe, wird pthread statisch eingebunden! Nur "libpthreadGC2-static.a" in "libpthreadGC2.a" umbenennen reicht aber nicht...

Schlussfolgerung: Die "pthread.a" scheint von x264 bevorzugt zu werden und bindet pthread dynamisch ein. Die "libpthreadGC2-static.a" akzeptiert er nur als "libpthreadGC2.a"

Selur

Danke für die Info werde ich morgen mal ausprobieren und berichten.

Cu Selur

Selur

Sorry, komme aktuell nicht dazu, bin etwas angeschlagen (39.5°C Fieber + Erkältung :() + hab heute die sx264 public Alpha herausgebracht.

Cu Selur

LoRd_MuldeR

Zitat von Selur

Sorry, komme aktuell nicht dazu, bin etwas angeschlagen (39.5°C Fieber + Erkältung :() + hab heute die sx264 public Alpha herausgebracht.

Dann mal gute besserung!

Solange kannst du ja einfach eines der verfügbaren Builds benutzen, die sind normalerweise schon statisch gegen pthread gelinkt:
http://forum.doom9.org/ • http://komisar.gin.by/ • http://x264.nl/

(Die x264.exe selber zu bauen ist eigentlich nur nötig, wenn man "ungewöhnliche" Patches benutzen will. Oder wenn man sich unbedingt mit MinGW/GG beschäftigen will ^^)

Selur

Hatte mit dem selber bauen angefangen als der Pipe-Output kaputt war und der Patch es ne ganze Weile nicht ins SVN geschafft hatte.
Ist jetzt mehr Gewohnheit + will demnächst noch ein komplett Paket für sx264 herausbringen, muss dafür aber erst noch die Lizenzen der ganzen Tools durchlesen die ich verwende.

Danke für den Tipp mit dem umbenennen der Dateien, scheint jetzt zu gehen.

Cu Selur

LoRd_MuldeR

Solange du die x264.exe als eigenständiges Programm aufrust, sollte es da keine Probleme mit der Lizenz geben.
Wenn du libx264 jedoch gegen dein Programm linkst (statisch oder dynamisch), müsstest du dein Programm ebenfalls unter GPL Lizenz stellen...

Selur

Ne, nutze bewusst alles als eigenständiges Programm. Muss aber die Tage mal gucken wie es bie den anderen tools aussieht,.. (momentan dank Erkältung einfach nicht die Konstitution längere Lizenztexte zu lesen ;))

Fällt mir ein:
Müsste man nicht eigentlich Lizenzabgaben an die MPEG-LA abgeben, da wenn man einen x264 build (einen h.264 Encoder) zur Verfügung stellt?

LoRd_MuldeR

Zitat von Selur

Fällt mir ein:
Müsste man nicht eigentlich Lizenzabgaben an die MPEG-LA abgeben, da wenn man einen x264 build (einen h.264 Encoder) zur Verfügung stellt?

Wenn man sein Programm kommerziell vermarktet, dann müsste man das wohl schon

Und mir fällt ein: Wenn dein Programm auf dem Qt Framework aufbaut, musst du ohnehin eine "proprietäre" Qt Lizenz erwerben oder aber dein Programm unter GPL Lizenz stellen, um es mit der "OpenSource" Qt Lizenz kompatibel zu machen. In wiefern die anderen beteiligten Tools/Bibliotheken damit vereinbar sind, weiß ich nicht...

Selur

Die QT Lizenz sollte kein Problem sein, da ja durchaus mein Tool selber unter einer anderen Lizenz stehen darf, als die anderen Tools die ich verwende.

Zitat

Wenn man sein Programm kommerziell vermarktet, dann müsste man das wohl schon

Dachte das gilt generell und nicht nur wenn man kommerziell agiert, oder wird es einfach ansonsten geduldet?

Cu Selur

LoRd_MuldeR

Zitat von Selur

Die QT Lizenz sollte kein Problem sein, da ja durchaus mein Tool selber unter einer anderen Lizenz stehen darf, als die anderen Tools die ich verwende.

Qt hat ein duales Lizenz-System. Wenn du die "kostenlose" GPL Variante von Qt benutzt, dann musst du deine Anwendung unter GPL Lizenz stellen. Anwendungen, die gegen GPL Bibliotheken linken, müssen ebenfalls unter GPL Lizenz stehen! Und das ist hier eindeutig der Fall. Bei LGPL Bibliotheken dürfen auch Nicht-GPL Programm dynamisch linken. Aber die "freie" Qt Version steht unter GPL, nicht LGPL. Es gibt auch die "kostenpflichtige" Variante von Qt. Deren Lizenz erlaubt es, deine Anwendung unter eine beliebige (proprietäre) Lizenz zu stellen. Ist aber halt nicht kostenlos...

Zitat von Selur

Dachte das gilt generell und nicht nur wenn man kommerziell agiert, oder wird es einfach ansonsten geduldet?

Cu Selur

Glaub es wird geduldet. Bin aber kein Rechtsexperte. Bei der Masse an x264 GUI's würd ich mir nich allzuviele Sorgen machen...

Selur

Ja, da ich aber nix dynamisch Linke muss nur meine Anwendung unter der GPL stehen, was aber nichts mit den Anwendungen zu tun hat die verwende.

Cu Selur

LoRd_MuldeR

Zitat von Selur

Ja, da ich aber nix dynamisch Linke muss nur meine Anwendung unter der GPL stehen, was aber nichts mit den Anwendungen zu tun hat die verwende.

Cu Selur

Ja, wenn dein Programm auf dem Qt Framework aufbaut, linkt es zwangsläufig gegen die Qt Bibliotheken und muss dementsprechend unter GPL Lizenz stehen (sofern du keine "kommerzielle" Qt Lizenz erwerben möchtest und mit der "OpenSource" Variante arbeitest). Das gilt natürlich nicht für die anderen Tools, die zwar zu deinem Projekt gehören, aber nur als eigenständige Programme aufgerufen werden. Bei denen müsstest du nur sicherstellen, dass man sie als "Redistrirbutable" mit verteilen darf. Zum Beispiel ist das bei Nero AAC nicht der Fall! Deshalb habe ich bei LameXP nur einen Download-Link eingebaut und muss den Benutzer bitten, die neroAaacEnc.exe selbst von deren Web-Seite herunterzuladen...

Selur

Zitat

Zum Beispiel ist das bei Nero AAC nicht der Fall! .. muss den Benutzer bitten, die neroAaacEnc.exe selbst von deren Web-Seite herunterzuladen...

Wird bei mir wohl später vergleichbar laufen müssen.

Zitat

Ja, wenn dein Programm auf dem Qt Framework aufbaut, linkt es zwangsläufig gegen die Qt Bibliotheken und muss dementsprechend unter GPL Lizenz stehen

Stimmt. Hab auch mal aus Interesse bei QT nachgefragt was den momentan ne commercial license kostet, da ja nichts genaues auf deren Homepage zu finden ist. (sx264 wird zwar trotzdem OpenSource bleiben, aber man weiß ja nie.)

Cu Selur

Jetzt mitmachen!