Attól tartok, hogy véletlenül összekeverted a pastebin-t a git levlistával, és biztos vagyok benne, hogy ezt eredetileg utóbbira szeretted volna elküldeni, kiegészítve az általad használt fordító nevével és verziójával.
Kizarolag a BSD-k alatt letezik a "gmake" intezmenye, tekintve hogy n darab make van. Linuxon, illetve Darwin/OS X-en cakk-pakk egy darab make van. A kerdessel igazabol konkretizalni akartam, hogy vajon melyik BSD lehet, mert van vagy negy alapvetoen kulonbozo, es darabonkent ket-harom fork.
-- Blog | @hron84 Üzemeltető macik
Listazd ide, hol van meg gmake parancs. GNU Make van sok helyen, pl. az MinGW/MSYS is azt hasznalja, de mindenutt "make" a parancs, egyszeruen azert, mert az a default.
-- Blog | @hron84 Üzemeltető macik
$ >which make
/usr/bin/make
$ >which gmake
/usr/bin/gmake
$ >ls -lL /usr/bin/{make,gmake}
-rwxr-xr-x 1 root system 241885 Feb 17 2004 /usr/bin/gmake
-r-xr-xr-x 1 bin bin 129326 Jul 02 2013 /usr/bin/make
$ >make --version
make: Not a recognized flag: -
usage: make [-einqrst] [-k|-S] [-d[A|adg[1|2]mstv]] [-D variable] [-f makefile] [-j [jobs]] [variable=value ...] [target ...]
$ >gmake --version
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
$ >lslpp -w /usr/bin/make
File Fileset Type
----------------------------------------------------------------------------
/usr/bin/make bos.adt.base Symlink
$ >rpm -qf /usr/bin/gmake
make-3.80-1
$ >uname
AIX
Csak hogy tisztázzuk: a FreeBSD az alaprendszer részeként hoz egy make parancsot, amellyel pl. a ports-fa is kezelhető ill. az alaprendszer fordítható (azaz a fordításának menete szabályozható).
Pont ugyanúgy hoz egy cp, ls, stb. parancsot, amely különbözik a gnu-féle verzióktól (egyszeri felhasználóként kb. annyit látok, hogy egy-két paraméter máshogy van, ha van egyáltalán, és pl. a find parancs esetén mindenféleképpen meg kell adni útvonalat, ahol keresni akarsz, míg a gnu-félétől elhagyható. Gondolom, forráskódban jelentősebb az eltérés.).
Szóval ez az alap-make és a gnu-féle make nem kompatibilis, a legtöbb program fordításához pedig gnu-féle make kell (a gnu-specifikus Makefile-okat a FreeBSD-féle make nem feltétlen tudja értelmezni).
Tehát az alap make mellé kell a gnu make is, ami az ütközések elkerülése miatt gmake néven települ.
A csomagok/portok, amennyiben szükséges, a fordításhoz a gmake-et használják (azaz nem a make parancsot, hanem a gmake parancsot kell kiadni, ennyi a nagy változás).
Másrészt nem vagyok C/C++-expert, de a linkelt hiba szerintem nem a make/gmake esetleges keveredésére vezethető vissza.
Ezekkel mind tisztaban vagyok, csak nem vagyok hajlando minden egyes esetben amikor elokerul a tema, feloldalas elemzest adni a BSD lelkivilagarol. Gondoltam, hogy van a kozosseg annyira ertelmes, hogy ha a "gmake intezmenye"-rol beszelek, akkor egy kis gondolkodast kovetoen levagja, hogy vajh mi a teturol is lehet szo. Mert elvben informatikusok volnank, akiknek nem kell mindent alapoktol magyarazni. Gyanitom azonban, hogy valahol felremehetett a kommunikacio.
A linkelt hiba szerintem se a make/gmake kulonbseg forrasa, azonban, mivel egy darab pastebin URL-t kaptunk, ahol csak egy gcc kimenet talalhato, nem teljesen vilagos, hogy peldaul milyen GCC verzio, milyen binutils, meg egyaltalan, mi az a forditasi kornyezet, ahol a git forrasa ezt a hibat adhatja. Amennyire en tudom, szamolatlan mennyisegu BSD hasznaloja van a Gitnek, ha valami ordas problema lenne vele, akkor az egybol feltunne igy eleg sok embernek. Ahhoz azonban, hogy az ember _segito_ szandekkal alljon hozza a problemahoz (igen, akkor is, ha egy olyan emberrol van szo, akit amugy nem feltetlen kedvel), ahhoz legalabb nagyjabol be kellene hatarolni dolgokat. Ha tudom, hogy pl. FreeBSD 10.0 -rol beszelgetunk, akkor annak mar utana tudok nezni, hogy milyen gcc meg milyen binutils, meg egyaltalan, milyen kornyezet van benne. De ha valaki csak idetol egy gcc hibat, azzal semmit se tudok kezdeni.
A gmake itt csak es kizarolagosan azert kerult kepbe, mert a kimenetbol ez volt az _egyetlen_ konkretum, amin el tudtam indulni, es mivel a BSD rendszereken kivul nagyon-nagyon keves esetben hasznaljak a "gmake" nevet a GNU Make binarisanak, ezert olyan 87-90%-os valoszinuseggel megtippeltem, hogy esetleg, talan, valoszinuleg valamelyik BSD szarmazekrol lehet szo. Ha megnezed, semmilyen mas ertelemben nem utaltam a make-ra, azt a hiba okanak nem jeloltem meg.
-- Blog | @hron84 Üzemeltető macik
Eléggé félreérthető volt, hogy mire is gondolsz. Én legalábbis félreértettem.
milyen gcc meg milyen binutils
FreeBSD 10-től már nem gcc, hanem clang van (bár a gcc telepíthető). Illetve nincs binutils se, FreeBSD-nél ez is az alaprendszer része (már régóta, gondolom, a kezdetektől).
Ohh, bennem fel sem merult, hogy Mr. Added Gmore kepes egy udvarias koszonomot (az elso kommentre), vagy netalantan egy "kosz, megoldva" kommentet elengedni, szoval egyaltalan nem volt min felizgatnom magam. Pusztan kivancsi lettem volna, hol jon elo a problema, hogy ha en magam is beleakadok, akkor tudjam, mit kell keresni.
Ami azt illeti, egyebkent elolvastam a masodik kommentet, ahol ezt irtad:
"tekintve hogy git 1.x-2.x-latestig gccvel és clanggal is ez van"
Na, ebbol mindent meg lehet tudni, ami rank tartozik. Semmit. Peldaul a gcc verzioszamat meg csak veletlenul sem emlited, pedig erre mar az elso kommentben is felhivtak a figyelmedet. De persze senki nem varja toled, hogy el tudod olvasni egy komment _legelso_ sorat teljes egeszeben. Pedig ez meg lehet platformspecifikus problema, amire lehetne egy jo patchet adni a gitnek (nem feltetlen neked, de mas lehet, hogy szivesen megcsinalna), hogy ne legyenek "linuxizmusok" benne. De persze konnyebb sirni...
-- Blog | @hron84 Üzemeltető macik
először odaírtam, de az RMS lábujjairól vakart lábgombapéldányaim sértőnek találták az intellektusukra nézve. mire én ezt válaszoltam:
- de drága gombatenyészetem, a soraimat hragya is olvashatja, és mégoly' magas értelmező képességeinek olümposzi magaslatait latba vetve sem fogja érteni az implikációt, hogy talán nem a gcc verziók közötti hatalmas különbségek fognak számítani, ha a clang is ugyanazt mondja
...végül azonban engedtem a rábeszélésnek, illetve az optimizmusomnak :(
Nem tudom, kuldtel-e mar be valaha valakinek ilyen jellegu bugreportot (barmelyik opensource projektnek), de en mar kuldtem, nem is egyet, es az elso harom kerdes a platform/disztribucio, a kernelverzio, es a fordito verzioszama. Ezek nem azert fontosak, mert a gcc es a clang kozti kulonbseg szamitana, hanem azert, hogy ha barki segiteni akar neked, akkor reprodukalni tudja a kornyezetedet, amiben a problema elofordult. Ha peldaul annyi pluszt irtal volna, hogy a FreeBSD alapertelmezett GCC es Clang verzioival jon elo a hiba, akkor azzal mar nagyon sokkal beljebb van az, aki segiteni akar, mert felhuz virtualis gepbe egy FreeBSD-t, es megnezi a problemat. De ha csak annyit nyogsz oda, hogy gcc es clanggal is ugyanez van, en meg Linuxon nem tudom elohozni, akkor csak annyit tudok visszabofogni, hogy "works4me" amivel te boldogabb nem leszel, viszont lehet egy jot ocsarolni a kozosseget megintcsak. Holott valojaban nem a kozosseg a hulye.
-- Blog | @hron84 Üzemeltető macik
Hozzászólások
Attól tartok, hogy véletlenül összekeverted a pastebin-t a git levlistával, és biztos vagyok benne, hogy ezt eredetileg utóbbira szeretted volna elküldeni, kiegészítve az általad használt fordító nevével és verziójával.
Amúgy:
$ head -n4 builtin/describe.c
#include "cache.h"
#include "lockfile.h"
#include "commit.h"
#include "tag.h"
$ cat tag.h
#ifndef TAG_H
#define TAG_H
#include "object.h"
extern const char *tag_type;
struct tag {
struct object object;
struct object *tagged;
char *tag;
unsigned long date;
};
extern struct tag *lookup_tag(const unsigned char *sha1);
extern int parse_tag_buffer(struct tag *item, const void *data, unsigned long size);
extern int parse_tag(struct tag *item);
extern struct object *deref_tag(struct object *, const char *, int);
extern struct object *deref_tag_noverify(struct object *);
#endif /* TAG_H */
én ettől nem tartok, tekintve hogy git 1.x-2.x-latestig gccvel és clanggal is ez van, szóval valami szokásos linuxizmus, nem ér meg erőfeszítést
Worksforus.
vigyázó szemeitek ne párizsra, hanem a topicra vessétek, ahol nem az áll hogy "miért zabálják a szemetet egyes igénytelen egyedek"
"párizsra"
Ez olyan mocsári törpés volt a magyar nyelv nagy őrzőjétől.
--
trey @ gépház
>mocsári törpés
0/10 tried too hard
Pedig ez betalált. Ebből is látszik, hogy nem vagy úriember!
-
JVM futásidejű monitorozása
>betalált
miért?
loop
>d-de betalált!!4XD
Kíváncsi voltam, hogyan reagálsz a saját stílusodra ;) Segítek, ez a gond, és elég frappáns volt a törpés hasonlat.
|-/
Szerintem atsiklottal afelett, hogy: "flame" meg "gmoore". Vigyazz, ha segiteni probalsz neki elkezd Teged is fikazni :-)
/sza2
gmoore: igen, nyugodtan kitehetsz az uzenofaladra.
Mondasz egy platformot melle? Gondolom valami BSD.
--
Blog | @hron84
Üzemeltető macik
C
Figyelj mar, a BSD kernel nem fordul Windowson, a BSD miert egy darab szemet amugy? Hat az is C, nem?
--
Blog | @hron84
Üzemeltető macik
lazán kapcsolódik: te amúgy autista is vagy ugye? nem bántásból.
Nem tudok rola.
--
Blog | @hron84
Üzemeltető macik
Miért kellene "valami BSD"-nek lennie? BSD alatt is van C fordító (gcc, clang). Sőt, még le is fordul, ahogy nézem, mindenféle patkolás nélkül.
Kizarolag a BSD-k alatt letezik a "gmake" intezmenye, tekintve hogy n darab make van. Linuxon, illetve Darwin/OS X-en cakk-pakk egy darab make van. A kerdessel igazabol konkretizalni akartam, hogy vajon melyik BSD lehet, mert van vagy negy alapvetoen kulonbozo, es darabonkent ket-harom fork.
--
Blog | @hron84
Üzemeltető macik
>Kizarolag a BSD-k alatt letezik a "gmake" intezmenye
added
Listazd ide, hol van meg gmake parancs. GNU Make van sok helyen, pl. az MinGW/MSYS is azt hasznalja, de mindenutt "make" a parancs, egyszeruen azert, mert az a default.
--
Blog | @hron84
Üzemeltető macik
>Listazd ide, hol van meg gmake parancs
parancs, az konkrétan sehol
http://forums.xilinx.com/t5/Embedded-Linux/bin-bash-gmake-command-not-f…
https://wiki.archlinux.org/index.php/Xilinx_ISE_WebPACK#GNU_make
Ez konkretan a Xilinx lamasaga, gyakorlatilag egy if feltetelbe kerul a kompatibilitas.
--
Blog | @hron84
Üzemeltető macik
Hint:
http://www.xilinx.com/images/tools/ise_support_lg.GIF
Windows és Linux rendszeren kívül látsz bármi mást?
$ >which make
/usr/bin/make
$ >which gmake
/usr/bin/gmake
$ >ls -lL /usr/bin/{make,gmake}
-rwxr-xr-x 1 root system 241885 Feb 17 2004 /usr/bin/gmake
-r-xr-xr-x 1 bin bin 129326 Jul 02 2013 /usr/bin/make
$ >make --version
make: Not a recognized flag: -
usage: make [-einqrst] [-k|-S] [-d[A|adg[1|2]mstv]] [-D variable] [-f makefile] [-j [jobs]] [variable=value ...] [target ...]
$ >gmake --version
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
$ >lslpp -w /usr/bin/make
File Fileset Type
----------------------------------------------------------------------------
/usr/bin/make bos.adt.base Symlink
$ >rpm -qf /usr/bin/gmake
make-3.80-1
$ >uname
AIX
Csak hogy tisztázzuk: a FreeBSD az alaprendszer részeként hoz egy make parancsot, amellyel pl. a ports-fa is kezelhető ill. az alaprendszer fordítható (azaz a fordításának menete szabályozható).
Pont ugyanúgy hoz egy cp, ls, stb. parancsot, amely különbözik a gnu-féle verzióktól (egyszeri felhasználóként kb. annyit látok, hogy egy-két paraméter máshogy van, ha van egyáltalán, és pl. a find parancs esetén mindenféleképpen meg kell adni útvonalat, ahol keresni akarsz, míg a gnu-félétől elhagyható. Gondolom, forráskódban jelentősebb az eltérés.).
Szóval ez az alap-make és a gnu-féle make nem kompatibilis, a legtöbb program fordításához pedig gnu-féle make kell (a gnu-specifikus Makefile-okat a FreeBSD-féle make nem feltétlen tudja értelmezni).
Tehát az alap make mellé kell a gnu make is, ami az ütközések elkerülése miatt gmake néven települ.
A csomagok/portok, amennyiben szükséges, a fordításhoz a gmake-et használják (azaz nem a make parancsot, hanem a gmake parancsot kell kiadni, ennyi a nagy változás).
Másrészt nem vagyok C/C++-expert, de a linkelt hiba szerintem nem a make/gmake esetleges keveredésére vezethető vissza.
Ezekkel mind tisztaban vagyok, csak nem vagyok hajlando minden egyes esetben amikor elokerul a tema, feloldalas elemzest adni a BSD lelkivilagarol. Gondoltam, hogy van a kozosseg annyira ertelmes, hogy ha a "gmake intezmenye"-rol beszelek, akkor egy kis gondolkodast kovetoen levagja, hogy vajh mi a teturol is lehet szo. Mert elvben informatikusok volnank, akiknek nem kell mindent alapoktol magyarazni. Gyanitom azonban, hogy valahol felremehetett a kommunikacio.
A linkelt hiba szerintem se a make/gmake kulonbseg forrasa, azonban, mivel egy darab pastebin URL-t kaptunk, ahol csak egy gcc kimenet talalhato, nem teljesen vilagos, hogy peldaul milyen GCC verzio, milyen binutils, meg egyaltalan, mi az a forditasi kornyezet, ahol a git forrasa ezt a hibat adhatja. Amennyire en tudom, szamolatlan mennyisegu BSD hasznaloja van a Gitnek, ha valami ordas problema lenne vele, akkor az egybol feltunne igy eleg sok embernek. Ahhoz azonban, hogy az ember _segito_ szandekkal alljon hozza a problemahoz (igen, akkor is, ha egy olyan emberrol van szo, akit amugy nem feltetlen kedvel), ahhoz legalabb nagyjabol be kellene hatarolni dolgokat. Ha tudom, hogy pl. FreeBSD 10.0 -rol beszelgetunk, akkor annak mar utana tudok nezni, hogy milyen gcc meg milyen binutils, meg egyaltalan, milyen kornyezet van benne. De ha valaki csak idetol egy gcc hibat, azzal semmit se tudok kezdeni.
A gmake itt csak es kizarolagosan azert kerult kepbe, mert a kimenetbol ez volt az _egyetlen_ konkretum, amin el tudtam indulni, es mivel a BSD rendszereken kivul nagyon-nagyon keves esetben hasznaljak a "gmake" nevet a GNU Make binarisanak, ezert olyan 87-90%-os valoszinuseggel megtippeltem, hogy esetleg, talan, valoszinuleg valamelyik BSD szarmazekrol lehet szo. Ha megnezed, semmilyen mas ertelemben nem utaltam a make-ra, azt a hiba okanak nem jeloltem meg.
--
Blog | @hron84
Üzemeltető macik
Eléggé félreérthető volt, hogy mire is gondolsz. Én legalábbis félreértettem.
FreeBSD 10-től már nem gcc, hanem clang van (bár a gcc telepíthető). Illetve nincs binutils se, FreeBSD-nél ez is az alaprendszer része (már régóta, gondolom, a kezdetektől).
>nem teljesen vilagos, hogy peldaul milyen GCC verzio, milyen binutils, meg egyaltalan
nem kell felizgatnod magad: egyáltalán fel sem merült, hrogy el tudod olvasni a második kommentet
Ohh, bennem fel sem merult, hogy Mr. Added Gmore kepes egy udvarias koszonomot (az elso kommentre), vagy netalantan egy "kosz, megoldva" kommentet elengedni, szoval egyaltalan nem volt min felizgatnom magam. Pusztan kivancsi lettem volna, hol jon elo a problema, hogy ha en magam is beleakadok, akkor tudjam, mit kell keresni.
Ami azt illeti, egyebkent elolvastam a masodik kommentet, ahol ezt irtad:
"tekintve hogy git 1.x-2.x-latestig gccvel és clanggal is ez van"
Na, ebbol mindent meg lehet tudni, ami rank tartozik. Semmit. Peldaul a gcc verzioszamat meg csak veletlenul sem emlited, pedig erre mar az elso kommentben is felhivtak a figyelmedet. De persze senki nem varja toled, hogy el tudod olvasni egy komment _legelso_ sorat teljes egeszeben. Pedig ez meg lehet platformspecifikus problema, amire lehetne egy jo patchet adni a gitnek (nem feltetlen neked, de mas lehet, hogy szivesen megcsinalna), hogy ne legyenek "linuxizmusok" benne. De persze konnyebb sirni...
--
Blog | @hron84
Üzemeltető macik
>Peldaul a gcc verzioszamat
először odaírtam, de az RMS lábujjairól vakart lábgombapéldányaim sértőnek találták az intellektusukra nézve. mire én ezt válaszoltam:
- de drága gombatenyészetem, a soraimat hragya is olvashatja, és mégoly' magas értelmező képességeinek olümposzi magaslatait latba vetve sem fogja érteni az implikációt, hogy talán nem a gcc verziók közötti hatalmas különbségek fognak számítani, ha a clang is ugyanazt mondja
...végül azonban engedtem a rábeszélésnek, illetve az optimizmusomnak :(
Nem tudom, kuldtel-e mar be valaha valakinek ilyen jellegu bugreportot (barmelyik opensource projektnek), de en mar kuldtem, nem is egyet, es az elso harom kerdes a platform/disztribucio, a kernelverzio, es a fordito verzioszama. Ezek nem azert fontosak, mert a gcc es a clang kozti kulonbseg szamitana, hanem azert, hogy ha barki segiteni akar neked, akkor reprodukalni tudja a kornyezetedet, amiben a problema elofordult. Ha peldaul annyi pluszt irtal volna, hogy a FreeBSD alapertelmezett GCC es Clang verzioival jon elo a hiba, akkor azzal mar nagyon sokkal beljebb van az, aki segiteni akar, mert felhuz virtualis gepbe egy FreeBSD-t, es megnezi a problemat. De ha csak annyit nyogsz oda, hogy gcc es clanggal is ugyanez van, en meg Linuxon nem tudom elohozni, akkor csak annyit tudok visszabofogni, hogy "works4me" amivel te boldogabb nem leszel, viszont lehet egy jot ocsarolni a kozosseget megintcsak. Holott valojaban nem a kozosseg a hulye.
--
Blog | @hron84
Üzemeltető macik