checking whether gcc supports -W... no
checking whether gcc supports -Wall... no
checking whether gcc supports -Wwrite-strings... no
checking whether gcc supports -Wc++-compat... no
checking whether gcc supports -Wstrict-prototypes... no
checking whether gcc supports -Wshadow=local... no
checking whether gcc supports -pedantic ... no
Ezt valahol úgy sikerül előadni (volt is már ilyen, ha nem is emlékszem, pontosan melyik terméknél), hogy a CFLAGS-ba én betettem ugyan, hogy -maix64, de az bizonyos esetekben nem jut el a gcc-hez. Van viszont az OBJECT_MODE=64, amitől az Assembler 64-bites módban szeretne működni. A következmény nyilvánvaló:
Assembler:
/tmp//ccnagLXJ.s: line 14: Only .llong should be used for relocatable expressions.
Első tippem: a CPPFLAGS-ba is beleteszem, hogy -maix64, hátha valami változik.
Szerk: Na, működött? Persze. Kivéve, ahol a CPPFLAGS sem jut el a gcc-hez... No mindjárt lesz neki egy gcc64 meg egy g++64, azt' megnézheti magát...
Szerk: és most:
aix-thread.c: In function 'void fetch_regs_user_thread(regcache*, pthdb_pthread_t)':
aix-thread.c:1184:37: error: invalid conversion from 'long long unsigned int*' to 'uint64_t* {aka long unsigned int*}' [-fpermissive]
supply_gprs64 (regcache, ctx.gpr);
Így elsőre azt mondanám, hogy a -fpermissive opciónak vesznie kell... Szerk: fordítva, kötelezően belegyógyítjuk a g++64 scriptbe.
Szerk: valaki eldugta a mkdtemp-et... Adta rendetlen kölykei!
compile/compile.c: In function 'const char* get_compile_file_tempdir()':
compile/compile.c:235:32: error: 'mkdtemp' was not declared in this scope
tempdir_name = mkdtemp (tname);
Szerk: 5.3-as problémának tűnik:
ld: 0711-317 ERROR: Undefined symbol: .getthrds(int, thrdsinfo64*, int, long*, int)
Szerk: AIX6.1 esetén procinfo.h-ban:
extern int getthrds( pid_t, void *, int, tid_t *, int );
extern int getthrds64( pid_t, void *, int, tid64_t *, int );
És a /usr/lib/boot/unix nevű komponens exportálja. Még 5.3-ban is.
Szerk: mondjuk a hibaüzenetet gondosabban is elolvashattam volna:
ld: 0711-317 ERROR: Undefined symbol: .getthrds(int, thrdsinfo64*, int, long*, int)
Ezúton is csókoltatom Supstrup urat!
- NevemTeve blogja
- A hozzászóláshoz be kell jelentkezni
- 539 megtekintés
Hozzászólások
Note to self: azért felírhattam volna, hogy mi volt az 'mkdtemp'-re a megoldás... Ugyanis gcc-frissítés után visszajött a probléma.
Sőt:
$ gdb
exec(): 0509-036 Cannot load program gdb because of the following errors:
0509-130 Symbol resolution failed for gdb because:
0509-136 Symbol _ZNKSt9type_infoeqERKS_ (number 222) is not exported from
dependent module /usr/local/lib64/libstdc++.so.6.
Mondjuk ha csak ez az egyetlen szimbóleum hiányzik, az százalékosan olyan kevés, hogy attól még nevezhetjük felülről kompatibilisnek a libstdc++.6.0.21-et a 6.0.19-cel...
Szerk: _XOPEN_SOURCE >= 700 kell a mkdtemp-hez (stdlib.h)
Sajnos a <standards.h> ezt sokallja, és visszaállítja 600-ra. Ha nem látnám nem hinném el:(
Azon kívül a gcc "include-fixed' változattal jön, amiben nincs benne a mkdtemp. Mondhatni rossz a karmája ennek a 'mkdtemp'-nek.
- A hozzászóláshoz be kell jelentkezni
Nohát, ez érdekes egybeesés, nekem is mkdtemp problémám van:
AIX5.3, cmake-3.18.1 kellene forduljon, ehelyett:
ld: 0711-317 ERROR: Undefined symbol: .mkdtempÉs ez még csak az előkészítés, vagyis az a rész, amikor csinál egy ideiglenes cmake-t, hogy azzal megcsinálhassa a cmake-t. Természetesen nem Obelix kutyája jut erről eszembe.
Szerk: kezdem azt hinni, hogy AIX5.3 esetén az XOPEN_SOURCE sem segít, hanem gyorsan gányolnom kell az mktemp-ből és az mkdir-ből egy mkdtemp-et. Persze kellő óvatossággal, ne essek pofára, ha a haxor épp a két hívás között hoz létre egy épp olyan nevű könyvtárat, hogy eltérítse a programunkat (vagyis a tulajdonos, csoport, jogbitek azok lesznek, amiket ő megadott, nem az, amit a mkdtemp-től várok, hogy csináljon (euid, egid, 0700))
- A hozzászóláshoz be kell jelentkezni