Re: powerpc64-gcc 5.2 vintages get L". . ." type wrong compared to Char for FreeBSD for lib32 compiling

[Mark Millard]

[This time I'm explicit about a patch-gcc-freebsd-powerpc64 update and I report 
that with the change the PowerMac G5 hosted powerpc64-gcc based buildworld 
attempt completed, including WITH_LIB32= and WITH_BOOT= being involved. (But it 
may not be until tomorrow or later until I test if such a build actually works 
for installworld and reboot.)]

> On 2015-Dec-6, at 2:44 PM, Andreas Tobler  wrote:
> 
> On 06.12.15 22:34, Mark Millard wrote:
>> [I picked the lists that I did because powerpc64-gcc is the external
>> toolchain created to allow modern powerpc64 builds.]
>> 
>> For the powerpc64-gcc 5.2 vintages. . . (using my environment's path
>> as an example)
>> 
>> /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.2.0/gcc/config/rs6000/freebsd64.h
>> has:
>> 
>>> /* rs6000.h gets this wrong for FreeBSD.  We use the GCC defaults
>>> instead.  */ #undef WCHAR_TYPE #define WCHAR_TYPE
>>> (TARGET_64BIT ? "int" : "long int") #undef  WCHAR_TYPE_SIZE #define
>>> WCHAR_TYPE_SIZE 32
>> 
>> That type in quotes ends up being the base type for L". . ."
>> notation, for example. Probably the char notation as well (L'?').
>> 
>> For FreeBSD Char compatibility in a powerpc64 lib32 context that
>> "long int" should effectively instead be "int", making the
>> conditional above technically unnecessary.
>> 
>> This blocks compiling lib32 source code that uses such notations as
>> L". . .": "long int" is not compatible with FreeBSD's Char in the
>> powerpc64 environment's 32 bit environment. Some compiler message are
>> explicit about the base types of pointers that result for the
>> mismatches: that is how I know that "long int" is in use for L". . ."
>> and "int" is the other base type involved.
>> 
>> (Yes, freebsd64.h appears to be used for lib32, at least on
>> powerpc64.  By contrast freebsd.h agrees for the WCHAR_TYPE_SIZE but
>> only undef's WCHAR_TYPE, presuming gcc defaults are correct for
>> FreeBSD as far as the type goes. It might need a more explicit type
>> to be sure of a Char match for that freebsd.h file's context.)
>> 
>> The 4.9 vintages of powerpc64-gcc were messed up the same way, as was
>> noted at the time.
> 
> I'll take care.
> 
> Andreas

(I make no claim that this note manages to preserve tabs and such in the diff 
-u text.)

To turn my earlier note into an actual updated 
devel/powerpc64-gcc/files/patch-gcc-freebsd-powerpc64 instead of the more vague 
words would involve adding what would look something like:

> @@ -304,7 +317,7 @@
>  
>  /* rs6000.h gets this wrong for FreeBSD.  We use the GCC defaults instead.  
> */
>  #undef WCHAR_TYPE
> -#defineWCHAR_TYPE  (TARGET_64BIT ? "int" : "long int")
> +#defineWCHAR_TYPE  "int"
>  #undef  WCHAR_TYPE_SIZE
>  #define WCHAR_TYPE_SIZE 32
> 

(It is what I actually tested.)

The full patch-gcc-freebsd-powerpc64 would then look something like:

> --- gcc/config/rs6000/freebsd64.h.orig  2015-01-05 04:33:28.0 -0800
> +++ gcc/config/rs6000/freebsd64.h   2015-12-09 00:14:28.520684000 -0800
> @@ -65,6 +65,13 @@
>  #define INVALID_64BIT "-m%s not supported in this configuration"
>  #define INVALID_32BIT INVALID_64BIT
>  
> +/* Use LINUX64 instead of FREEBSD64 for compat with e.g. sysv4le.h */
> +#ifdef LINUX64_DEFAULT_ABI_ELFv2
> +#define ELFv2_ABI_CHECK (rs6000_elf_abi != 1)
> +#else
> +#define ELFv2_ABI_CHECK (rs6000_elf_abi == 2)
> +#endif
> +
>  #undef  SUBSUBTARGET_OVERRIDE_OPTIONS
>  #define SUBSUBTARGET_OVERRIDE_OPTIONS  \
>do   \
> @@ -84,6 +91,12 @@
>   rs6000_isa_flags &= ~OPTION_MASK_RELOCATABLE; \
>   error (INVALID_64BIT, "relocatable"); \
> }   \
> + if (ELFv2_ABI_CHECK)  \
> +   {   \
> + rs6000_current_abi = ABI_ELFv2;   \
> + if (dot_symbols)  \
> +   error ("-mcall-aixdesc incompatible with -mabi=elfv2"); \
> +   }   \
>   if (rs6000_isa_flags & OPTION_MASK_EABI)  \
> {   \
>   rs6000_isa_flags &= ~OPTION_MASK_EABI;\
> @@ -304,7 +317,7 @@
>  
>  /* rs6000.h gets this wrong for FreeBSD.  We use the GCC defaults instead.  
> */
>  #undef WCHAR_TYPE
> -#defineWCHAR_TYPE  (TARGET_64BIT ? "int" : "long int")
> +#defineWCHAR_TYPE  "int"
>  #undef  WCHAR_TYPE_SIZE
>  #define WCHAR_TYPE_SIZE 32
>  


I can report that a make buildworld with the following WITH/WITHOUT src.conf 
type options competed based on the rebuilt powerpc64-gcc. (WITHOUT_CLANG= and 
WITHOUT_LLDB= were just to save time. The context is already libc++ based and 
so 

svn: E000022: ?\A0@@?\C8V @8@@@?\84?\D4

[O. Hartmann]

I get this in my /usr/ports directory out of the blue when doing a svn update:

[...]
cd /usr/ports; /usr/bin/svn update
Updating '.':
svn: E22: Error converting entry in directory '/usr/ports/www/links1' to 
UTF-8
svn: E22: Can't convert string from native encoding to 'UTF-8':
svn: E22: ?\A0@@?\C8V
 @8@@@?\84?\D4
*** Error code 1

Stop.
make: stopped in /usr/ports


What is up here?

Kind regards,
Oliver


pgpynNkBjdJoQ.pgp
Description: OpenPGP digital signature

Re: svn: E000022: ?\A0@@?\C8V @8@@@?\84?\D4

[Greg 'groggy' Lehey]

On Wednesday,  9 December 2015 at 20:58:37 +0100, Matthias Apitz wrote:
> El día Wednesday, December 09, 2015 a las 08:51:05PM +0100, O. Hartmann 
> escribió:
>
>> Found a strange entry in ports/www/links1:
>>
>>
>> total 435
>>  766755 -rw-r--r-- 1 root  wheel  uarch0B Dec  9 16:26 
>> ???@@?V?@8?@@@??
>>   29563 drwxr-xr-x 3 root  wheel  uarch8B Dec  9 16:26 ./
>
> The file was created at Dec 9 16:26, i.e. today. Any chance to get
> the name of the dirent in hex to understand the CodePoints?

Not that I know of, but you can get them in octal with the -B option
to ls.  That must say something about how old the option is :-)

Greg
--
Sent from my desktop computer.
Finger g...@freebsd.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua


signature.asc
Description: PGP signature

Re: svn: E000022: ?\A0@@?\C8V @8@@@?\84?\D4

[O. Hartmann]

Am Wed, 9 Dec 2015 19:42:20 +0100
Kurt Jaeger  schrieb:

> Hi!
> 
> > I get this in my /usr/ports directory out of the blue when doing a svn 
> > update:
> > 
> > [...]
> > cd /usr/ports; /usr/bin/svn update
> [...]
> 
> I tested it on one host, can't reproduce.
> 


Found a strange entry in ports/www/links1:


total 435
 766755 -rw-r--r-- 1 root  wheel  uarch0B Dec  9 16:26 
???@@?V?@8?@@@??
  29563 drwxr-xr-x 3 root  wheel  uarch8B Dec  9 16:26 ./
1911685 drwxr-xr-x  2384 root  wheel  uarch  2.3K Dec  8 18:01 ../
  29601 -rw-r--r-- 1 root  wheel  uarch  474B Jul  9 19:51 Makefile
  29582 -rw-r--r-- 1 root  wheel  uarch  128B Jul  9 19:51 distinfo
  29571 drwxr-xr-x 2 root  wheel  uarch5B Jul  9 19:51 files/
  29584 -rw-r--r-- 1 root  wheel  uarch  557B Jul  9 19:51 pkg-descr
  29599 -rw-r--r-- 1 root  wheel  uarch   30B Jul  9 19:51 pkg-plist

This host's /usr/ports tree resides on a ZFS volume.

Aftere deletion of the folder and another svn update, everything was as normal 
as before.


pgpDdUBiNeOqw.pgp
Description: OpenPGP digital signature

Re: svn: E000022: ?\A0@@?\C8V @8@@@?\84?\D4

[Matthias Apitz]

El día Wednesday, December 09, 2015 a las 08:51:05PM +0100, O. Hartmann 
escribió:

> Am Wed, 9 Dec 2015 19:42:20 +0100
> Kurt Jaeger  schrieb:
> 
> > Hi!
> > 
> > > I get this in my /usr/ports directory out of the blue when doing a svn 
> > > update:
> > > 
> > > [...]
> > > cd /usr/ports; /usr/bin/svn update
> > [...]
> > 
> > I tested it on one host, can't reproduce.
> > 
> 
> 
> Found a strange entry in ports/www/links1:
> 
> 
> total 435
>  766755 -rw-r--r-- 1 root  wheel  uarch0B Dec  9 16:26 
> ???@@?V?@8?@@@??
>   29563 drwxr-xr-x 3 root  wheel  uarch8B Dec  9 16:26 ./

The file was created at Dec  9 16:26, i.e. today. Any chance to get the
name of the dirent in hex to understand the CodePoints?

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de,  http://www.unixarea.de/  ☎ 
+49-176-38902045
___
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"