ports-mgmt/synth: Upgrade version 1.43 => 1.50

xtaz@ this is really weird. I think the problem lies in the ports version of ncurses. I forcibly compiled adacurses and synth to use the base ncurses and it worked fine then on FreeBSD.
The ports version of ncurses works fine on DragonFly. I'm not sure what's going on here.
 
xtaz@ this testcase proves that ports ncurses is broken on FreeBSD:
https://leaf.dragonflybsd.org/~marino/testcurses.shar

you can try it yourself. with make, it will build "hello" program with base ncurses, and it works fine.
with make WITH_PORTS=1, the hello program will be linked with base ncurses.

On FreeBSD, the latter shows nothing. On DragonFly it works as expected.
Unfortunately the ncurses port is unmaintained!
 
xtaz@ okay, it seems that the testcase failed because the base ncurses headers were used to build it but it was linked with ports ncurses library.
The same thing might be going on here somewhere.
 
xtax@ (and everyone else),
I think I have this fixed.
  1. update ports tree
  2. rebuild devel/adacurses
  3. rebuild ports-mgmt/synth
steps 2 and 3 can be done within synth (maybe move to text mode if you want), and then pkg rem synth followed by pkg add <path/to/packages>/All/synth-1.54_1.txz
 
Hi! Sorry I didn't reply until now. I missed your first post and then saw that you had reproduced it yourself on the second. I can confirm that the latest update fixes the problem. Everything is back to normal. Thanks! I had just switched it to text mode temporarily so that I could see what was going on, but it's back to ncurses mode now that it's rebuilt itself.
 
I like Synth. Good job.

Is it possible, or do you have any plans to make it possible, to cross-build ports from, say, amd64 to armv6? What would it take to accomplish that?
 
I guess it would be possible if it mimicked poudriere (search for "qemu" here: https://github.com/freebsd/poudrier...fa9517ae2/src/share/poudriere/common.sh#L1621)
There's a guy that figured out how to make things faster here: http://phaq.phunsites.net/2015/10/1...ce-optimization-for-poudriere/comment-page-1/

It seems to me what ports really needs is to support cross-compiling natively. Often the problem is that port generates a tool that generates a source file and that tool can't run on the host system. It's an interesting problem.

Given how slow QEMU is anyway, though, with today's tree, there's not any benefit from using synth over poudriere for ARM cross compiling. Is there? Both are going to be slow compared to host building, so one might as well use poudriere for this specific use case.

gdelmatto is on the right track though, true cross compiling would be the answer. I don't have any machines to cross-compile to ATM.
 
Uniballer said:
I like Synth. Good job.

Is it possible, or do you have any plans to make it possible, to cross-build ports from, say, amd64 to armv6? What would it take to accomplish that?
Click to expand...

Uniballer@, check out this 2-year old presentation by bapt: http://www.slideshare.net/eurobsdcon/baptiste-daroussin-crosscompiling-ports
I never saw it before, but it's really informative about what's needed for native cross compiling. I suppose it's just a state-of-the-tree briefing because my guess is nobody is working to finish the "to do" work on it.
 
You must log in or register to reply here.
Back
Top