tenfourfox - should it be in the MacPorts repo?

[Christopher Jones]

> On 11 Oct 2018, at 6:51 pm, Ken Cunningham <ken.cunningham.webuse at gmail.com> wrote:
> 
> 
> On 2018-10-11, at 10:38 AM, Christopher Jones wrote:
> 
>> Hi,
>> 
>> A couple other thoughts…
>> 
>> What platforms do you see this being useful on ? I know that older platforms, but newer than 10.4, also have issues with SSL/TLS support. Presumably this would also be useful on these ? 10.6 ? 10.7 ?
> 
> I use it daily on Intel 10.4 to 10.7. Probably also useful on 10.8. I'm not sure when Safari started supporting TLSv1.2, but any version of Safari that doesn't support that is pretty much SOL. Also, the mainstream Firefox is 10.9+ only now, and that is likely to move up soon.

I guessed as much, and of course would greatly increase the usefulness of the port. Much less ’niche’...

>> 
>> Related to the above what is the rationale for forcing the use of gcc 4.8 ? Is it this is the only compiler that works on OSX 10.4, or is it a constraint from the tenforfox code itself ? Could you not, on slightly newer platforms use a newer gcc build ? I presume that up to date firefox releases must build fine with newer gcc versions …. gcc6 works on 10.6, for instance. This I guess might help to mitigate a bit that platforms that would require the ’strip7’ patch…
> 
> 
> I and others have been trying to move tenfourfox up to gcc6 or gcc7, and in the process I learned WAY more about the nuances of loop-unrolling and tree-optimization than I ever thought possible. 
> 
> Here's an example <https://github.com/classilla/tenfourfox/issues/464 <https://github.com/classilla/tenfourfox/issues/464>>
> 
> The tenfourfox codebase is moving along to build on newer gcc versions, but being a one-man show at present, he's more focused on keeping it up to date. gcc48 is c++11 compatible, builds the codebase, and is buildable on all the older systems at present, so it's not a bad compromise for the moment.

OK, that makes sense.

it sounds to me then that the main issue to sort out is how best to introduce the ’strip7’ patch, as this should be done first. A standard alone port is one option, but I confess on the face of it its not obvious to me its the best option here. 

Chris

> 
> 
>> 
>> ( Not important, but what does the 7 mean in strip7 ? )
> 
> If you get to know Cameron at all, you will come to find out that he is:
> 
> 1. smart
> 2. funny
> 3. loves Macs
> 
> I have no idea what it means :>
> 
> 
> Ken
> 
> 
> 
>> 
>> Chris
>> 
>>> On 11 Oct 2018, at 6:29 pm, Christopher Jones <jonesc at hep.phy.cam.ac.uk <mailto:jonesc at hep.phy.cam.ac.uk>> wrote:
>>> 
>>> Hi,
>>> 
>>>> Apparently, gcc48 can produce some zero-length N_SECTs that error out in the default strip command but don't need to. Cameron made them warnings instead (see below). We are reaching the limits of my knowledge about this issue right about now … 
>>> 
>>> OK. Looking at that patch, because all it does is make what was an error into a warning, I see no (technical) reason why this could not just be applied (conditionally, only on those old systems that need tenfoxfox)  to the main cctools build, so patch the strip command built by that. 
>>> 
>>>> 
>>>> I made strip7 a separate port from cctools so as to stay out of Jeremy's way. It could easily be a subport of cctools, but I have a feeling Jeremy may not like that much ;>
>>> 
>>> You will not know without asking, and anyway cctools is open maintainer as well….
>>> 
>>> I think you should consider preparing a PR that does the above, and then let the discussion start on the PR itself. If/When that gets approved, adding the tenfourfox port should be straight forward..
>>> 
>>> cheers Chris
>>> 
>>>> 
>>>> Ken
>>>> 
>>>> 
>>>> 
>>>> ==
>>>> 
>>>> --- misc/strip.c.orig	2018-09-16 17:48:10.000000000 -0700
>>>> +++ misc/strip.c	2018-09-16 17:52:04.000000000 -0700
>>>> @@ -2951,11 +2951,15 @@
>>>> 		n_type = symbols[i].n_type;
>>>> 		n_sect = symbols[i].n_sect;
>>>> 		if((n_type & N_TYPE) == N_SECT){
>>>> -		    if(n_sect == 0 || n_sect > nsects){
>>>> +		    if(n_sect > nsects){
>>>> 			error_arch(arch, member, "bad n_sect for symbol "
>>>> 				   "table entry %d in: ", i);
>>>> 			return(FALSE);
>>>> 		    }
>>>> +		    if (n_sect == 0) {
>>>> +			warning_arch(arch, member, "ignoring n_sect == 0 for "
>>>> +				"symbol table entry %d in: ", i);
>>>> +		    }
>>>> 		    s_flags = sections[n_sect - 1]->flags;
>>>> 		}
>>>> 		n_desc = symbols[i].n_desc;
>>>> @@ -2967,11 +2971,15 @@
>>>> 		n_type = symbols64[i].n_type;
>>>> 		n_sect = symbols64[i].n_sect;
>>>> 		if((n_type & N_TYPE) == N_SECT){
>>>> -		    if(n_sect == 0 || n_sect > nsects){
>>>> +		    if(n_sect > nsects){
>>>> 			error_arch(arch, member, "bad n_sect for symbol "
>>>> 				   "table entry %d in: ", i);
>>>> 			return(FALSE);
>>>> 		    }
>>>> +		    if (n_sect == 0) {
>>>> +			warning_arch(arch, member, "ignoring n_sect == 0 for "
>>>> +				"symbol table entry %d in: ", i);
>>>> +		    }
>>>> 		    s_flags = sections64[n_sect - 1]->flags;
>>>> 		}
>>>> 		n_desc = symbols64[i].n_desc;
>>>> 
>>>> ========
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20181011/2848e48e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1930 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20181011/2848e48e/attachment-0001.bin>