Re: 'porting' AMD compiler suite
On 04/14/16 01:54, Andriy Gapon wrote: On 14/04/2016 05:38, William A. Mahaffey III wrote: All seems OK w/ the system headers (I know, shocking ), the required files defining a '__uintptr_t' are in fact unconditionally included, so it must be something else (bad defines somewhere, or ). I am still chasing Apologies, but are you serious?.. $ fgrep -r __uintptr_t /usr/include/ ... /usr/include/x86/_types.h:typedef __uint64_t __uintptr_t; /usr/include/x86/_types.h:typedef __uint32_t __uintptr_t; ... This is on an amd64 head system. Yeah, but the includes are several layers down, took me a bit to figure them out. Did I mention that I am *NOT* a kernel hacker ? Most of this system-type stuff is greek to me, organizationally (which is obviously on me, nobody else). I am still getting compile errors, looks like config.h has a bad line in it, which '#define's uintptr_t as 'unsigned long', which would give a compile error when used in a typedef line. I am going to just comment the offending lines out of the config.h file & see if I get farther. If so (or not, actually), I'll post back for either closure or hints. -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On 04/14/16 02:48 AM, Andriy Gapon wrote: > On 14/04/2016 05:38, William A. Mahaffey III wrote: >> All seems OK w/ the system headers (I know, shocking ), the required >> files >> defining a '__uintptr_t' are in fact unconditionally included, so it must be >> something else (bad defines somewhere, or ). I am still chasing > > Apologies, but are you serious?.. > > $ fgrep -r __uintptr_t /usr/include/ > ... > /usr/include/x86/_types.h:typedef __uint64_t __uintptr_t; > /usr/include/x86/_types.h:typedef __uint32_t __uintptr_t; > ... > > This is on an amd64 head system. #ifdef __LP64__ ... typedef __uint64_t __uintptr_t; #else ... typedef __uint32_t __uintptr_t; #endif Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: 'porting' AMD compiler suite
On 14/04/2016 05:38, William A. Mahaffey III wrote: > All seems OK w/ the system headers (I know, shocking ), the required files > defining a '__uintptr_t' are in fact unconditionally included, so it must be > something else (bad defines somewhere, or ). I am still chasing Apologies, but are you serious?.. $ fgrep -r __uintptr_t /usr/include/ ... /usr/include/x86/_types.h:typedef __uint64_t __uintptr_t; /usr/include/x86/_types.h:typedef __uint32_t __uintptr_t; ... This is on an amd64 head system. -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On 04/13/16 02:51, Mehmet Erol Sanliturk wrote: On Wed, Apr 13, 2016 at 12:02 AM, William A. Mahaffey III wrote: On 04/12/16 21:05, Kevin P. Neal wrote: On Tue, Apr 12, 2016 at 03:32:21PM -0453, William A. Mahaffey III wrote: A bit of poking around yields a 'typedef __uintptr_t uintptr_t;' statement as line 78 of /usr/include/sys/_stdint.h, where __uintptr_t isn't defined anywhere Any clues ? TIA & have a good one. *C'mon* Someone throw me a bone :-). Whassup here, this can't be the 1st time this has happened where is __uintptr_t defined/typedef'ed ? % find /usr/include/ -type f -print | xargs grep __uintptr_t You'll need to follow the includes backwards until you get to an include that looks like it is meant to be directly included. That particular command is left as an exercise to the reader. *Boooyah*, thanks. It looks like some GNU-ism, still chasing ;-). Thanks again. -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ There are differences between FreeBSD and Linux include directory places . Assume , it it is possible to build Open64 in Linux , but it is failing in FreeBSD due to unfound files : There is a need to specify include directories ( -I ) in make files correctly for the FreeBSD being equivalent to Linux include directories . For example , some files are specified in Linux as #include , but in FreeBSD as #include . Mehmet Erol Sanliturk . ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" All seems OK w/ the system headers (I know, shocking ), the required files defining a '__uintptr_t' are in fact unconditionally included, so it must be something else (bad defines somewhere, or ). I am still chasing -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On Wed, Apr 13, 2016 at 12:02 AM, William A. Mahaffey III wrote: > On 04/12/16 21:05, Kevin P. Neal wrote: > >> On Tue, Apr 12, 2016 at 03:32:21PM -0453, William A. Mahaffey III wrote: >> >>> A bit of poking around yields a 'typedef __uintptr_t uintptr_t;' statement as line 78 of /usr/include/sys/_stdint.h, where __uintptr_t isn't defined anywhere Any clues ? TIA & have a good one. >>> *C'mon* Someone throw me a bone :-). Whassup here, this can't be >>> the 1st time this has happened where is __uintptr_t >>> defined/typedef'ed ? >>> >> % find /usr/include/ -type f -print | xargs grep __uintptr_t >> >> You'll need to follow the includes backwards until you get to an include >> that looks like it is meant to be directly included. That particular >> command >> is left as an exercise to the reader. >> > > > *Boooyah*, thanks. It looks like some GNU-ism, still chasing ;-). Thanks > again. > > -- > > William A. Mahaffey III > > -- > > "The M1 Garand is without doubt the finest implement of war > ever devised by man." >-- Gen. George S. Patton Jr. > > ___ > > The following page perhaps may contain some useful information : http://grokbase.com/t/sc/osunix-dev/0932bgy1rs/opensolaris-open64-port-1st-round-patch-review Mehmet Erol Sanliturk ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On Wed, Apr 13, 2016 at 12:02 AM, William A. Mahaffey III wrote: > On 04/12/16 21:05, Kevin P. Neal wrote: > >> On Tue, Apr 12, 2016 at 03:32:21PM -0453, William A. Mahaffey III wrote: >> >>> A bit of poking around yields a 'typedef __uintptr_t uintptr_t;' statement as line 78 of /usr/include/sys/_stdint.h, where __uintptr_t isn't defined anywhere Any clues ? TIA & have a good one. >>> *C'mon* Someone throw me a bone :-). Whassup here, this can't be >>> the 1st time this has happened where is __uintptr_t >>> defined/typedef'ed ? >>> >> % find /usr/include/ -type f -print | xargs grep __uintptr_t >> >> You'll need to follow the includes backwards until you get to an include >> that looks like it is meant to be directly included. That particular >> command >> is left as an exercise to the reader. >> > > > *Boooyah*, thanks. It looks like some GNU-ism, still chasing ;-). Thanks > again. > > -- > > William A. Mahaffey III > > -- > > "The M1 Garand is without doubt the finest implement of war > ever devised by man." >-- Gen. George S. Patton Jr. > > ___ > > There are differences between FreeBSD and Linux include directory places . Assume , it it is possible to build Open64 in Linux , but it is failing in FreeBSD due to unfound files : There is a need to specify include directories ( -I ) in make files correctly for the FreeBSD being equivalent to Linux include directories . For example , some files are specified in Linux as #include , but in FreeBSD as #include . Mehmet Erol Sanliturk . ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On Wed, Apr 13, 2016 at 12:02 AM, William A. Mahaffey III wrote: > On 04/12/16 21:05, Kevin P. Neal wrote: > >> On Tue, Apr 12, 2016 at 03:32:21PM -0453, William A. Mahaffey III wrote: >> >>> A bit of poking around yields a 'typedef __uintptr_t uintptr_t;' statement as line 78 of /usr/include/sys/_stdint.h, where __uintptr_t isn't defined anywhere Any clues ? TIA & have a good one. >>> *C'mon* Someone throw me a bone :-). Whassup here, this can't be >>> the 1st time this has happened where is __uintptr_t >>> defined/typedef'ed ? >>> >> % find /usr/include/ -type f -print | xargs grep __uintptr_t >> >> You'll need to follow the includes backwards until you get to an include >> that looks like it is meant to be directly included. That particular >> command >> is left as an exercise to the reader. >> > > > *Boooyah*, thanks. It looks like some GNU-ism, still chasing ;-). Thanks > again. > > -- > > William A. Mahaffey III > > -- > > "The M1 Garand is without doubt the finest implement of war > ever devised by man." >-- Gen. George S. Patton Jr. > > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > If you search __uintptr_t in Google , you will find many links about its possible places . Mehmet Erol Sanliturk ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On 04/12/16 21:05, Kevin P. Neal wrote: On Tue, Apr 12, 2016 at 03:32:21PM -0453, William A. Mahaffey III wrote: A bit of poking around yields a 'typedef __uintptr_t uintptr_t;' statement as line 78 of /usr/include/sys/_stdint.h, where __uintptr_t isn't defined anywhere Any clues ? TIA & have a good one. *C'mon* Someone throw me a bone :-). Whassup here, this can't be the 1st time this has happened where is __uintptr_t defined/typedef'ed ? % find /usr/include/ -type f -print | xargs grep __uintptr_t You'll need to follow the includes backwards until you get to an include that looks like it is meant to be directly included. That particular command is left as an exercise to the reader. *Boooyah*, thanks. It looks like some GNU-ism, still chasing ;-). Thanks again. -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On 04/11/16 08:58, William A. Mahaffey III wrote: On 04/10/16 18:57, William A. Mahaffey III wrote: On 04/10/16 18:09, Peter Jeremy wrote: On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" wrote: configure process completed OK, but created a Makefile w/ what seems to be a bunch of linuxisms in conditionals to allow compilation for different architectures, see attached orig-Makefile. Have you tried using gmake, rather than the base make? OK, I tried gmake & got the attached, lotta '#include malloc.h' all over the place, I'll have to handle that file-by-file :-/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" OK fixed the above w/ find & sed, now I have: . . . . In file included from ../../../../x86_open64-4.5.2.1-1/osprey/driver/objects.c:59: ./option_names.h:944: warning: built-in function 'fma' declared as non-function C /usr/src/contrib/obj/osprey/targdir/driver/../../../../x86_open64-4.5.2.1-1/osprey/driver/phases.c In file included from ../../../../x86_open64-4.5.2.1-1/osprey/driver/phases.c:69: ./option_names.h:944: warning: built-in function 'fma' declared as non-function ../../../../x86_open64-4.5.2.1-1/osprey/driver/phases.c: In function 'run_ar': ../../../../x86_open64-4.5.2.1-1/osprey/driver/phases.c:3144: warning: implicit declaration of function 'get_executable_dir_from_path' ../../../../x86_open64-4.5.2.1-1/osprey/driver/phases.c:3144: warning: initialization makes pointer from integer without a cast C /usr/src/contrib/obj/osprey/targdir/driver/../../../../x86_open64-4.5.2.1-1/osprey/driver/run.c In file included from ../../../../x86_open64-4.5.2.1-1/osprey/driver/run.c:86: ./option_names.h:944: warning: built-in function 'fma' declared as non-function C /usr/src/contrib/obj/osprey/targdir/driver/../../../../x86_open64-4.5.2.1-1/osprey/driver/special_options.c In file included from ../../../../x86_open64-4.5.2.1-1/osprey/driver/special_options.c:63: ./option_names.h:944: warning: built-in function 'fma' declared as non-function GENversion_hg.c C /usr/src/contrib/obj/osprey/targdir/driver/version_hg.c LD /usr/src/contrib/obj/osprey/targdir/driver/driver file_names.o: In function `get_object_file': file_names.c:(.text+0xe57): warning: warning: tempnam() possibly used unsafely; consider using mkstemp() gmake[3]: Leaving directory '/usr/src/contrib/obj/osprey/targdir/driver' gmake last gmake[3]: Entering directory '/usr/src/contrib/obj/osprey/targdir/driver' hg: not found rm -f opencc openCC openf90 ln -s driver opencc ln -s driver openCC ln -s driver openf90 gmake[3]: Leaving directory '/usr/src/contrib/obj/osprey/targdir/driver' gmake[2]: Leaving directory '/usr/src/contrib/obj/osprey/targdir/driver' gmake -C osprey/targdir/libiberty gmake[2]: Entering directory '/usr/src/contrib/obj/osprey/targdir/libiberty' C /usr/src/contrib/obj/osprey/targdir/libiberty/../../../../x86_open64-4.5.2.1-1/osprey/libiberty/alloca.c C /usr/src/contrib/obj/osprey/targdir/libiberty/../../../../x86_open64-4.5.2.1-1/osprey/libiberty/argv.c C /usr/src/contrib/obj/osprey/targdir/libiberty/../../../../x86_open64-4.5.2.1-1/osprey/libiberty/choose-temp.c C /usr/src/contrib/obj/osprey/targdir/libiberty/../../../../x86_open64-4.5.2.1-1/osprey/libiberty/concat.c In file included from /usr/include/sys/types.h:63, from ../../../../x86_open64-4.5.2.1-1/osprey/libiberty/concat.c:52: /usr/include/sys/_stdint.h:78: error: two or more data types in declaration specifiers /usr/include/sys/_stdint.h:78: error: two or more data types in declaration specifiers /usr/src/contrib/obj/osprey/../../x86_open64-4.5.2.1-1/osprey/linux/make/gcommonrules:148: recipe for target 'concat.o' failed gmake[2]: *** [concat.o] Error 1 gmake[2]: Leaving directory '/usr/src/contrib/obj/osprey/targdir/libiberty' Makefile:205: recipe for target 'libiberty' failed gmake[1]: *** [libiberty] Error 2 gmake[1]: Leaving directory '/usr/src/contrib/obj' Makefile:340: recipe for target 'build' failed gmake: *** [build] Error 2 8.01 real 6.34 user 0.57 sys A bit of poking around yields a 'typedef __uintptr_t uintptr_t;' statement as line 78 of /usr/include/sys/_stdint.h, where __uintptr_t isn't defined anywhere Any clues ? TIA & have a good one. *C'mon* Someone throw me a bone :-). Whassup here, this can't be the 1st time this has happened where is __uintptr_t defined/typedef'ed ? -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-ports@freebsd.org mailing list https://li
Re: 'porting' AMD compiler suite
On Sun, 10 Apr 2016, William A. Mahaffey III wrote: On 04/10/16 20:22, Warren Block wrote: On Sun, 10 Apr 2016, William A. Mahaffey III wrote: Or set the (g)make variable 'MAKE' to gmake & let it propogate What you are doing is, in effect, creating a port. If you create a real port, there are numerous tools to deal with just this sort of problem, like USES=gmake. The Porter's Handbook describes the whole process of creating a port: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ I wasn't planning to go that far to start with, but that could change. I am having to edit a largish # of the source files to comment out '#include ' lines, is there a way to automate that for port/pkg maintenance ? I haven't reviewed the porters-handbook (yet), but I have hit that snag to start with https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#slow-patch-automatic-replacements ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On 04/10/16 18:57, William A. Mahaffey III wrote: On 04/10/16 18:09, Peter Jeremy wrote: On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" wrote: configure process completed OK, but created a Makefile w/ what seems to be a bunch of linuxisms in conditionals to allow compilation for different architectures, see attached orig-Makefile. Have you tried using gmake, rather than the base make? OK, I tried gmake & got the attached, lotta '#include malloc.h' all over the place, I'll have to handle that file-by-file :-/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" OK fixed the above w/ find & sed, now I have: . . . . In file included from ../../../../x86_open64-4.5.2.1-1/osprey/driver/objects.c:59: ./option_names.h:944: warning: built-in function 'fma' declared as non-function C /usr/src/contrib/obj/osprey/targdir/driver/../../../../x86_open64-4.5.2.1-1/osprey/driver/phases.c In file included from ../../../../x86_open64-4.5.2.1-1/osprey/driver/phases.c:69: ./option_names.h:944: warning: built-in function 'fma' declared as non-function ../../../../x86_open64-4.5.2.1-1/osprey/driver/phases.c: In function 'run_ar': ../../../../x86_open64-4.5.2.1-1/osprey/driver/phases.c:3144: warning: implicit declaration of function 'get_executable_dir_from_path' ../../../../x86_open64-4.5.2.1-1/osprey/driver/phases.c:3144: warning: initialization makes pointer from integer without a cast C /usr/src/contrib/obj/osprey/targdir/driver/../../../../x86_open64-4.5.2.1-1/osprey/driver/run.c In file included from ../../../../x86_open64-4.5.2.1-1/osprey/driver/run.c:86: ./option_names.h:944: warning: built-in function 'fma' declared as non-function C /usr/src/contrib/obj/osprey/targdir/driver/../../../../x86_open64-4.5.2.1-1/osprey/driver/special_options.c In file included from ../../../../x86_open64-4.5.2.1-1/osprey/driver/special_options.c:63: ./option_names.h:944: warning: built-in function 'fma' declared as non-function GENversion_hg.c C /usr/src/contrib/obj/osprey/targdir/driver/version_hg.c LD /usr/src/contrib/obj/osprey/targdir/driver/driver file_names.o: In function `get_object_file': file_names.c:(.text+0xe57): warning: warning: tempnam() possibly used unsafely; consider using mkstemp() gmake[3]: Leaving directory '/usr/src/contrib/obj/osprey/targdir/driver' gmake last gmake[3]: Entering directory '/usr/src/contrib/obj/osprey/targdir/driver' hg: not found rm -f opencc openCC openf90 ln -s driver opencc ln -s driver openCC ln -s driver openf90 gmake[3]: Leaving directory '/usr/src/contrib/obj/osprey/targdir/driver' gmake[2]: Leaving directory '/usr/src/contrib/obj/osprey/targdir/driver' gmake -C osprey/targdir/libiberty gmake[2]: Entering directory '/usr/src/contrib/obj/osprey/targdir/libiberty' C /usr/src/contrib/obj/osprey/targdir/libiberty/../../../../x86_open64-4.5.2.1-1/osprey/libiberty/alloca.c C /usr/src/contrib/obj/osprey/targdir/libiberty/../../../../x86_open64-4.5.2.1-1/osprey/libiberty/argv.c C /usr/src/contrib/obj/osprey/targdir/libiberty/../../../../x86_open64-4.5.2.1-1/osprey/libiberty/choose-temp.c C /usr/src/contrib/obj/osprey/targdir/libiberty/../../../../x86_open64-4.5.2.1-1/osprey/libiberty/concat.c In file included from /usr/include/sys/types.h:63, from ../../../../x86_open64-4.5.2.1-1/osprey/libiberty/concat.c:52: /usr/include/sys/_stdint.h:78: error: two or more data types in declaration specifiers /usr/include/sys/_stdint.h:78: error: two or more data types in declaration specifiers /usr/src/contrib/obj/osprey/../../x86_open64-4.5.2.1-1/osprey/linux/make/gcommonrules:148: recipe for target 'concat.o' failed gmake[2]: *** [concat.o] Error 1 gmake[2]: Leaving directory '/usr/src/contrib/obj/osprey/targdir/libiberty' Makefile:205: recipe for target 'libiberty' failed gmake[1]: *** [libiberty] Error 2 gmake[1]: Leaving directory '/usr/src/contrib/obj' Makefile:340: recipe for target 'build' failed gmake: *** [build] Error 2 8.01 real 6.34 user 0.57 sys A bit of poking around yields a 'typedef __uintptr_t uintptr_t;' statement as line 78 of /usr/include/sys/_stdint.h, where __uintptr_t isn't defined anywhere Any clues ? TIA & have a good one. -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On 04/11/16 07:04, Torsten Zuehlsdorff wrote: On 11.04.2016 03:32, William A. Mahaffey III wrote: On 04/10/16 20:22, Warren Block wrote: On Sun, 10 Apr 2016, William A. Mahaffey III wrote: Or set the (g)make variable 'MAKE' to gmake & let it propogate What you are doing is, in effect, creating a port. If you create a real port, there are numerous tools to deal with just this sort of problem, like USES=gmake. The Porter's Handbook describes the whole process of creating a port: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" I wasn't planning to go that far to start with, but that could change. I am having to edit a largish # of the source files to comment out '#include ' lines, is there a way to automate that for port/pkg maintenance ? I haven't reviewed the porters-handbook (yet), but I have hit that snag to start with If everything is the same: try sed. :) Greetings, Torsten That's what I did, I was asking if there is some infrastructure in the ports system to automate that sort of stuff for port-maintenance -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On 11.04.2016 03:32, William A. Mahaffey III wrote: On 04/10/16 20:22, Warren Block wrote: On Sun, 10 Apr 2016, William A. Mahaffey III wrote: Or set the (g)make variable 'MAKE' to gmake & let it propogate What you are doing is, in effect, creating a port. If you create a real port, there are numerous tools to deal with just this sort of problem, like USES=gmake. The Porter's Handbook describes the whole process of creating a port: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" I wasn't planning to go that far to start with, but that could change. I am having to edit a largish # of the source files to comment out '#include ' lines, is there a way to automate that for port/pkg maintenance ? I haven't reviewed the porters-handbook (yet), but I have hit that snag to start with If everything is the same: try sed. :) Greetings, Torsten ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On 04/10/16 20:22, Warren Block wrote: On Sun, 10 Apr 2016, William A. Mahaffey III wrote: Or set the (g)make variable 'MAKE' to gmake & let it propogate What you are doing is, in effect, creating a port. If you create a real port, there are numerous tools to deal with just this sort of problem, like USES=gmake. The Porter's Handbook describes the whole process of creating a port: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" I wasn't planning to go that far to start with, but that could change. I am having to edit a largish # of the source files to comment out '#include ' lines, is there a way to automate that for port/pkg maintenance ? I haven't reviewed the porters-handbook (yet), but I have hit that snag to start with -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On Sun, 10 Apr 2016, William A. Mahaffey III wrote: Or set the (g)make variable 'MAKE' to gmake & let it propogate What you are doing is, in effect, creating a port. If you create a real port, there are numerous tools to deal with just this sort of problem, like USES=gmake. The Porter's Handbook describes the whole process of creating a port: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On 04/10/16 19:05, Mehmet Erol Sanliturk wrote: On Sun, Apr 10, 2016 at 4:10 PM, William A. Mahaffey III wrote: On 04/10/16 18:09, Peter Jeremy wrote: On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" wrote: configure process completed OK, but created a Makefile w/ what seems to be a bunch of linuxisms in conditionals to allow compilation for different architectures, see attached orig-Makefile. Have you tried using gmake, rather than the base make? H No, I didn't :-/ Did I mention pilot error ? I thought the system make was a version of gmake, but apparently not, right ? Thanks, I'll try that & see how it goes -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ FreeBSD make and GNU make are different species ( means not compatible ) . If you compare building of GCC in FreeBSD and Linux , you may model building of Open64 in FreeBSD with respect to building in Linux . If I were you , I would not work on Open64 because GCC is much better than Open64 with respect to my opinion . In Linux , I have checked Open64 for using it , but I have abandoned that idea , because at least it does not have 128 bit floating point numbers ( if it is not included yet ) . I have tried GCC & found it wanting, that's why I am looking for an alternative It may be said that it is abandoned : https://en.wikipedia.org/wiki/Open64 http://developer.amd.com/tools-and-sdks/cpu-development/x86-open64-compiler-suite/ https://sourceforge.net/projects/open64/ https://sourceforge.net/projects/open64/files/open64/ https://sourceforge.net/projects/open64/files/open64/Open64-5.0/ http://www.open64.net/ Mehmet Erol Sanliturk ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" I *think* AMD is still plodding along w/ their version, not certain of that -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On 04/10/16 19:09, Mehmet Erol Sanliturk wrote: On Sun, Apr 10, 2016 at 4:50 PM, William A. Mahaffey III wrote: On 04/10/16 18:09, Peter Jeremy wrote: On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" wrote: configure process completed OK, but created a Makefile w/ what seems to be a bunch of linuxisms in conditionals to allow compilation for different architectures, see attached orig-Makefile. Have you tried using gmake, rather than the base make? OK, I tried gmake & got the attached, lotta '#include malloc.h' all over the place, I'll have to handle that file-by-file :-/ -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ Important problem here is the following : In make files , there are other references to "make" commands , means , even you started from gmake , at the next make invocation , it will invoke the FreeBSD make . Therefore , you need to use a jail and replace the FreeBSD make with gmake , or , by traversing all of the make files , replace "make" invocations by "gmake" . Mehmet Erol Sanliturk ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" Or set the (g)make variable 'MAKE' to gmake & let it propogate -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On Sun, Apr 10, 2016 at 5:03 PM, Mehmet Erol Sanliturk < m.e.sanlit...@gmail.com> wrote: > On Sun, Apr 10, 2016 at 4:50 PM, William A. Mahaffey III > wrote: > > > On 04/10/16 18:09, Peter Jeremy wrote: > > > >> On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" < > w...@hiwaay.net> > >> wrote: > >> > >>> configure process completed OK, but created a Makefile w/ what seems to > >>> be a bunch of linuxisms in conditionals to allow compilation for > >>> different architectures, see attached orig-Makefile. > >>> > >> Have you tried using gmake, rather than the base make? > >> > >> > > > > OK, I tried gmake & got the attached, lotta '#include malloc.h' all over > > the place, I'll have to handle that file-by-file :-/ > > > > -- > > > > William A. Mahaffey III > > > > -- > > > > "The M1 Garand is without doubt the finest implement of war > > ever devised by man." > >-- Gen. George S. Patton Jr. > > > > > > ___ > > > > > > > Important problem here is the following : > > > In make files , there are other references to "make" commands , means , > even you started from gmake , at the next make invocation , it will invoke > the FreeBSD make . > > Therefore , you need to use a jail and replace the FreeBSD make with gmake > , or , by traversing all of the make files , replace "make" invocations by > "gmake" . > > > Mehmet Erol Sanliturk > Or just alias make to gmake in the build environment. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On Sun, Apr 10, 2016 at 4:50 PM, William A. Mahaffey III wrote: > On 04/10/16 18:09, Peter Jeremy wrote: > >> On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" >> wrote: >> >>> configure process completed OK, but created a Makefile w/ what seems to >>> be a bunch of linuxisms in conditionals to allow compilation for >>> different architectures, see attached orig-Makefile. >>> >> Have you tried using gmake, rather than the base make? >> >> > > OK, I tried gmake & got the attached, lotta '#include malloc.h' all over > the place, I'll have to handle that file-by-file :-/ > > -- > > William A. Mahaffey III > > -- > > "The M1 Garand is without doubt the finest implement of war > ever devised by man." >-- Gen. George S. Patton Jr. > > > ___ > > Important problem here is the following : In make files , there are other references to "make" commands , means , even you started from gmake , at the next make invocation , it will invoke the FreeBSD make . Therefore , you need to use a jail and replace the FreeBSD make with gmake , or , by traversing all of the make files , replace "make" invocations by "gmake" . Mehmet Erol Sanliturk ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On Sun, Apr 10, 2016 at 4:10 PM, William A. Mahaffey III wrote: > On 04/10/16 18:09, Peter Jeremy wrote: > >> On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" >> wrote: >> >>> configure process completed OK, but created a Makefile w/ what seems to >>> be a bunch of linuxisms in conditionals to allow compilation for >>> different architectures, see attached orig-Makefile. >>> >> Have you tried using gmake, rather than the base make? >> >> > > H No, I didn't :-/ Did I mention pilot error ? I thought the > system make was a version of gmake, but apparently not, right ? Thanks, > I'll try that & see how it goes > > -- > > William A. Mahaffey III > > -- > > "The M1 Garand is without doubt the finest implement of war > ever devised by man." >-- Gen. George S. Patton Jr. > > ___ > > FreeBSD make and GNU make are different species ( means not compatible ) . If you compare building of GCC in FreeBSD and Linux , you may model building of Open64 in FreeBSD with respect to building in Linux . If I were you , I would not work on Open64 because GCC is much better than Open64 with respect to my opinion . In Linux , I have checked Open64 for using it , but I have abandoned that idea , because at least it does not have 128 bit floating point numbers ( if it is not included yet ) . It may be said that it is abandoned : https://en.wikipedia.org/wiki/Open64 http://developer.amd.com/tools-and-sdks/cpu-development/x86-open64-compiler-suite/ https://sourceforge.net/projects/open64/ https://sourceforge.net/projects/open64/files/open64/ https://sourceforge.net/projects/open64/files/open64/Open64-5.0/ http://www.open64.net/ Mehmet Erol Sanliturk ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On 04/10/16 18:09, Peter Jeremy wrote: On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" wrote: configure process completed OK, but created a Makefile w/ what seems to be a bunch of linuxisms in conditionals to allow compilation for different architectures, see attached orig-Makefile. Have you tried using gmake, rather than the base make? OK, I tried gmake & got the attached, lotta '#include malloc.h' all over the place, I'll have to handle that file-by-file :-/ -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. Beginning background gmake all Initiated at 06:19:22 PM MCDT on Sunday, April 10, 2016 gmake first gmake[1]: Entering directory '/usr/src/contrib/obj' gmake[1]: Nothing to be done for 'first'. gmake[1]: Leaving directory '/usr/src/contrib/obj' gmake phony_targets gmake[1]: Entering directory '/usr/src/contrib/obj' gmake -C osprey/targdir/include gmake[2]: Entering directory '/usr/src/contrib/obj/osprey/targdir/include' echo '#ifndef __pathscale_defs_h' > pathscale_defs.h echo '#define __pathscale_defs_h' >> pathscale_defs.h echo '#define OPEN64_NAME_PREFIX "open"' >> pathscale_defs.h echo '#define OPEN64_MAJOR_VERSION_NUM 4' >> pathscale_defs.h echo '#define OPEN64_MINOR_VERSION_NUM 5' >> pathscale_defs.h echo '#define OPEN64_MAJOR_VERSION "4"' >> pathscale_defs.h echo '#define OPEN64_MINOR_VERSION "5"' >> pathscale_defs.h echo '#define OPEN64_FULL_VERSION "4.5.2.1"' >> pathscale_defs.h echo '#define OPEN64_GCC_VERSION "3.3.1"' >> pathscale_defs.h echo '#define OPEN64_GCC40_VERSION "4.0.2"' >> pathscale_defs.h echo '#define OPEN64_GCC42_VERSION "4.2.0"' >> pathscale_defs.h echo '#define OPEN64_INSTALL_PREFIX "/usr"' >> pathscale_defs.h echo '#define OPEN64_TARGET ""' >> pathscale_defs.h echo '#define OPEN64_PATCH_LEVEL "2.1"' >> pathscale_defs.h echo "#endif" >> pathscale_defs.h Making sys Making cmplrs Making libelf test: -a: unexpected operator test: -a: unexpected operator test: -a: unexpected operator test: -a: unexpected operator gmake[2]: Leaving directory '/usr/src/contrib/obj/osprey/targdir/include' gmake -C osprey/targdir/driver gmake[2]: Entering directory '/usr/src/contrib/obj/osprey/targdir/driver' hg: not found gmake first gmake[3]: Entering directory '/usr/src/contrib/obj/osprey/targdir/driver' hg: not found gmake[3]: Nothing to be done for 'first'. gmake[3]: Leaving directory '/usr/src/contrib/obj/osprey/targdir/driver' gmake driver gmake[3]: Entering directory '/usr/src/contrib/obj/osprey/targdir/driver' hg: not found C /usr/src/contrib/obj/osprey/targdir/driver/../../../../x86_open64-4.5.2.1-1/osprey/driver/errors.c C /usr/src/contrib/obj/osprey/targdir/driver/../../../../x86_open64-4.5.2.1-1/osprey/driver/file_utils.c C /usr/src/contrib/obj/osprey/targdir/driver/../../../../x86_open64-4.5.2.1-1/osprey/driver/lang_defs.c C /usr/src/contrib/obj/osprey/targdir/driver/../../../../x86_open64-4.5.2.1-1/osprey/driver/string_utils.c In file included from ../../../../x86_open64-4.5.2.1-1/osprey/driver/string_utils.c:43: /usr/include/malloc.h:3:2: error: #error " has been replaced by " /usr/src/contrib/obj/osprey/../../x86_open64-4.5.2.1-1/osprey/linux/make/gcommonrules:148: recipe for target 'string_utils.o' failed gmake[3]: *** [string_utils.o] Error 1 gmake[3]: Leaving directory '/usr/src/contrib/obj/osprey/targdir/driver' ../../../../x86_open64-4.5.2.1-1/osprey/driver/Makefile.gbase:225: recipe for target 'default' failed gmake[2]: *** [default] Error 2 gmake[2]: Leaving directory '/usr/src/contrib/obj/osprey/targdir/driver' Makefile:229: recipe for target 'driver' failed gmake[1]: *** [driver] Error 2 gmake[1]: Leaving directory '/usr/src/contrib/obj' Makefile:340: recipe for target 'build' failed gmake: *** [build] Error 2 0.52 real 0.29 user 0.23 sys Completed at 06:19:23 PM MCDT on Sunday, April 10, 2016 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On 04/10/16 18:09, Peter Jeremy wrote: On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" wrote: configure process completed OK, but created a Makefile w/ what seems to be a bunch of linuxisms in conditionals to allow compilation for different architectures, see attached orig-Makefile. Have you tried using gmake, rather than the base make? H No, I didn't :-/ Did I mention pilot error ? I thought the system make was a version of gmake, but apparently not, right ? Thanks, I'll try that & see how it goes -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" wrote: >configure process completed OK, but created a Makefile w/ what seems to >be a bunch of linuxisms in conditionals to allow compilation for >different architectures, see attached orig-Makefile. Have you tried using gmake, rather than the base make? -- Peter Jeremy signature.asc Description: PGP signature
