- Motorola Edge 40 - jó bőr
- Itt az első kép a 2024-es Nokia 3210-ről
- Google Pixel 8 Pro - mestersége(s) az intelligencia
- Redmi Note 10 Pro - majdnem minden stimmel
- Android alkalmazások - szoftver kibeszélő topik
- OnePlus 7 - magabiztos folytatás
- Samsung Galaxy S21 FE 5G - utóirat
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Digitális detox a Nokiától
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
Hirdetés
-
Agyi chipes gyártóba fektetett a kriptocég
it A Tether 200 millió dollárt fektet a Blackrock Neurotech agyi chipes vállalatba.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Május 7-én bulit tart a Huawei
ma Méghozzá Dubajban, ahol új termékek várhatók. Ezek a Watch Fit 3 és laptopok lehetnek, a Pura 70-es telefonok maradhatnak Kínában.
Új hozzászólás Aktív témák
-
escie
őstag
válasz VladimirR #3296 üzenetére
ugyan hardened gentoo-val nem foglalkoztam meg, de gondolom erdemes lenne egy ujabb gcc-t feltenni.
a 4-es szeriabol is van stabil gentoo-ra, ha debianon jo volt, szerintem itt is jo lenne.vagy van valami oka, hogy nem a legfrissebb stabil gcc-t hasznalod?
[ Szerkesztve ]
I'm back, baby!
-
Sipi
addikt
válasz VladimirR #3301 üzenetére
Eddig úgy vettem észre, hogy ha a gcc nem ad internal gcc error, contact the developers hibát, akkor az adott programmal van gond.
Az, hogy csak adott revtől jön elő, megerősít ebben. (Csak egy tipp: esetleg a forrás olyan dolgokat használna, amit a 4-es gcc-ben vezettek be.)Egyik gépemen 4.1.2, másikon 4.2-es gcc van, semmi gondom nem volt még egyikkel sem. A 4.1.2 stabil, használhatod. Szerintem érdemes áttérni a 4-es gcc-re, a plusz tudása miatt.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz VladimirR #3303 üzenetére
Ezt a hibát többnyire akkor dobja, ha kevés, és ezért elfogy a memória és swap, szerintem figyelmen kívül hagyhatod. Debugot miért kapcsolod be? Az is növeli a c++ programok fordításának memória-éhségét (ami egyébként is nagy).
Sorry, hardenedet elfelejtettem. Olyat nem használok. A /usr/profiles/hardened mappában tényleg hardmaszkolva van a teljes 4-es gcc sorozat... Pech.
Itt van pár infó arról, hogy mi vár rád, ha kézzel unmaszkolod a 4-es sorozatot, és hardeneddel akarod használni. (A 4-es még nincs felkészítve erre, ettől még működő kódot készít, csak az új funkciók nélkül.) Az utána következő válaszlevelek is érdekesek lehetnek.
Szerintem nem gcc hiba, a kmail is olyan, hogy a 800 mega memóriám eltűnik a fordítása közben. Evvan, én az rtorrentre gyanakszom. Nem hiba, inkább csak rosszul megírt kód lehet.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz VladimirR #3305 üzenetére
Tudom, írtad, csak azért írtam le megint, hogy jelezzem, ez a c++ internal error nem az az internal error, amikor a gcc fejlesztőknek sürgős bugreportot kell írni.
Memory leak csak a gcc-ben lehetne, de ennél a régi verziónál ezt kizárom. Leak lehetne még valamelyik külső lib meghívása miatt, akár a debugolás, akár a 4-es sorozat egzotikusabb dolgainak kihasználásánál. Ez megint kizárt. LD-nél sem lehet gond, mert itt a linkelésig el sem jut.
Én alapból kikapcsolom a make.conf-ban a debugot, totál felesleges... Van még az ipv6 kapcsoló, próbáld meg annak ki- és bekapcsolásával is (meg egy xmlrpc is, azt is), hátha... ipv6-tal más jellegű problémáim már adódtak (ruby, ha jól rémlik), a hibának látszólag semmi közük nem volt az ipv6-hoz.
Szerintem rtorrent-hiba, ez a cc-fájl nem is nagy (a 0.8.0-ás verzióban), lazán vinne kellene a gcc-nek.
Jut eszembe, anno a kmailnél volt olyan kiadás, amit ugyanígy nem tudtam lefordítani. Ott valamelyik -r revvel patkolták. Ma is zabál, de legalább lefordul. Ilyenkor várni szoktam, majd csak kijavítják.Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz VladimirR #3307 üzenetére
Jááááá, vagy nem mondtad, vagy nem értettem!
Csinálj hozzá ebuildet! Alap: egy létező rtorrent ebuild, átnevezed rtorrent-9999.ebuild-re. Az elejére beteszed egy másik -9999 ebuildből azt a részt, ahogy az svn-ből cincálja a dolgokat. Szépen megírod.
Vagy ha nem akarsz tökölni: innen letöltöd, beteszed a lokális Portage-fába (alapesetben /usr/local/portage szokott lenni). Aztán unmaszk meg emerge.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz VladimirR #3316 üzenetére
99%-ban mehetsz bugreportolni a gcc-teamnek.
Ha biztos akarsz lenni, próbáld ki (ugyanígy kézzel), hogyg++ -DHAVE_CONFIG_H -I. -I../.. -I./.. -g -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -MT dht_manager.o -MD -MP -MF .deps/dht_manager.Tpo -c -o dht_manager.o dht_manager.cc
Illetve egyre kevesebb parancssori kapcsolóval. (A -M-esekre gondolok, az include maradhat. )
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz VladimirR #3321 üzenetére
Jajj, de kár, hogy csak most olvasom, így nem írhattam be ugyanezt.
A 3.4.6 nem ancient. A 3-as és a 4-es két külön állatfaj, nem fognak elhajtani emiatt.
Én a bugs.gentoo.org-ot jobban csípem, mert az ottani fejlesztők nagyon szoros kapcsolatban szoktak állni a programfejlesztőkkel. A gentoo-t sok progrsmíró használja amolyan homokozóládának, mert a forráskód proglémái itt tutira előjönnek. Ha a Gentoo-soknak írsz, úgyis eljut a gcc-sekhez is.Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
válasz VladimirR #3343 üzenetére
Nem hagysz ki semmit. A kernel üzenetében az van, hogy force use of acpi=ht. Valami miatt bekapcsolja az ACPI-s HyperThreadinget, ami olyan procin, ami nem támogatja, egyenértékű azzal, mintha kikapcsolnád az acpi-támogatást.
Talán a kernelnek meg kellene adni az acpi=noht kapcsolót, vagy kísérletezni a különféle acpi= kapcsolókkal, hátha valamelyiknél nem akar HT-t.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
VladimirR
nagyúr
válasz VladimirR #3323 üzenetére
na, szuletett reakcio, egybol ketto is
a masodikkal viszont epp vitaban allok, mert szerintem a ket bug egy es ugyanaz, viszont o nem akarja megerteni, hogy ha emerge-vel, vagy make-kel forgditom, akkor nekem is felzabal minden ram-ot, majd elszall, s csak akkor segfault-ozik, ha kulon a dht_manager.cc sorat kimasolom a make kimenetebol, s azt akarom futtatni a megfelelo konyvtarbanno de nem is ezert irok, hanem mert keri, hogy adjak neki build.log-ot, viszont nekem egy arva build.log nincs a gepemen
mifele allat ez, s mi kell hozza, hogy teremjen?valaszaitokat elore is koszonom
-
Sipi
addikt
válasz VladimirR #3352 üzenetére
A bind-tools része az nslookup és a host is.
Az első haosnló a Wineshez, ha nem adsz, a default DNS servert használja, ha kötőjelet teszel utána, az utána álló nevet/címet.A fejlettebb host parancs pedig olyan, hogy ha egy nevet adsz meg neki, azt keresi, ha még egyet, azt a DNS szervernek veszi.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!
-
czappa
aktív tag
válasz VladimirR #3377 üzenetére
Köszi szépen!
to all:
A második (KMix-es) kérdésemhez:
A neten keresgélve látom, hogy - természetesen - nem egyedi a probléma.
Ideáig két megoldási javaslatot találtam:
a) KMixben -> Settings -> Configure KMix -> Restore volumes on login
Ez eddig is be volt x-elve, így nem ez a megoldás.
b) shellbe: alsactl store (rendszergazdaként)
Majd később jelentek, hogy ez bevált, avagy sem. -
VladimirR
nagyúr
válasz VladimirR #3388 üzenetére
a harmadik emerge --sync utan eszheztert
valszonuleg kozrejatszott, hogy volt egy kisebb hdd problema (virtualis gep es emerge -ave world kozben a host-on elfogyott a lemezterulet, igy beleszaladtam egy kisebb adatvesztesbe), de nem ertem, hogy miert nem pofozta helyre az elso sync
[ Szerkesztve ]
-
Sipi
addikt
válasz VladimirR #3389 üzenetére
Szerintem a fő rsync szerverrel van valami gond - pár napja időnként "file size not match" hibát kapok sync után. Random ebuildek más méretűek lesznek, mint ami a manifestben van.
Egyszer volt ilyen, amikor a fő rsync merevlemezei teljesen bekepáltak, későn kapcsolták le, és majd az összes alszerver átszinkronizált róla. Akkor azt hittem, szétment a vinyóm, de kiderült, csak a Portage fa volt rossz.
A websync vagy a daily snapshot megoldás ilyenkor.
Sipi
Mont-joie! Saint Denis! Je trépasse si je faiblis!