source-highlight and segfault on old PowerMac

2019-10-05 Thread Jeffrey Walton
Hi Everyone,

Syntax-Highlight results on an old PowerMac.

$ cat 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_textproc_source-highlight/source-highlight/main.log
...

:info:build make[2]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_textproc_source-highlight/source-highlight/work/source-highlight-3.1.8/src'
:info:build Making all in doc
:info:build make[2]: Entering directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_textproc_source-highlight/source-highlight/work/source-highlight-3.1.8/doc'
:info:build Makefile:1643: warning: overriding commands for target
`styleformatter.h.texinfo'
:info:build Makefile:1634: warning: ignoring old commands for target
`styleformatter.h.texinfo'
:info:build ../src/source-highlight --data-dir ../src/ -s java -f html
 --style-file ../src/default.style  -i ./Hello.java -o Hello1.html
:info:build ../src/source-highlight --data-dir ../src/ -s java -f html
 --style-file ../src/default.style  --input ./Hello.java --output
Hello2.html --doc
:info:build make[2]: *** [Hello2.html] Segmentation fault: 11
:info:build make[2]: *** Waiting for unfinished jobs
:info:build make[2]: *** [Hello1.html] Segmentation fault: 11
:info:build make[2]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_textproc_source-highlight/source-highlight/work/source-highlight-3.1.8/doc'
:info:build make[1]: *** [all-recursive] Error 1
:info:build make[1]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_textproc_source-highlight/source-highlight/work/source-highlight-3.1.8'
:info:build make: *** [all] Error 2
:info:build make: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_textproc_source-highlight/source-highlight/work/source-highlight-3.1.8'
:info:build Command failed:  cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_textproc_source-highlight/source-highlight/work/source-highlight-3.1.8"
&& /usr/bin/make -j2 -w all
:info:build Exit code: 2
:error:build Failed to build source-highlight: command execution failed
:debug:build Error code: CHILDSTATUS 16628 2
:debug:build Backtrace: command execution failed
:debug:build while executing
:debug:build "system {*}$notty {*}$nice $fullcmdstring"
:debug:build invoked from within
:debug:build "command_exec build"
:debug:build (procedure "portbuild::build_main" line 8)
:debug:build invoked from within
:debug:build "$procedure $targetname"
:error:build See
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_textproc_source-highlight/source-highlight/main.log
for details.


Re: sudo port selfupdate Doesn't Seem To Work

2019-10-05 Thread Michael Newman via macports-users
Yes. That was it. It failed because I had not yet accepted the Xcode license.

Once I did that 2.6.1 was actually installed and I was able upgrade installed 
ports.

Thank you.

> On Oct 6, 2019, at 07:26, Joshua Root  wrote:
> 
> Michael Newman wrote:
>> What’s going on here?
>> 
>> --->  Updating MacPorts base sources using rsync
>> MacPorts base version 2.5.4 installed,
>> MacPorts base version 2.6.1 downloaded.
>> --->  Updating the ports tree
>> --->  MacPorts base is outdated, installing new version 2.6.1
>> Installing new MacPorts release in /opt/local as root:wheel; permissions 0775
>> 
>> MrMuscle:~ mnewman$ sudo port selfupdate
>> --->  Updating MacPorts base sources using rsync
>> MacPorts base version 2.5.4 installed,
>> MacPorts base version 2.6.1 downloaded.
>> --->  Updating the ports tree
>> --->  MacPorts base is outdated, installing new version 2.6.1
>> Installing new MacPorts release in /opt/local as root:wheel; permissions 0775
>> 
>> It seems that 2.6.1 never actually gets installed.
> 
> You're likely running into this bug:
> 
> 
> Using the -v or -d flag to get more verbose output will show you what's
> actually happening, e.g. 'sudo port -d selfupdate'.
> 
> - Josh



Re: sudo port selfupdate Doesn't Seem To Work

2019-10-05 Thread Joshua Root
Michael Newman wrote:
> What’s going on here?
> 
> --->  Updating MacPorts base sources using rsync
> MacPorts base version 2.5.4 installed,
> MacPorts base version 2.6.1 downloaded.
> --->  Updating the ports tree
> --->  MacPorts base is outdated, installing new version 2.6.1
> Installing new MacPorts release in /opt/local as root:wheel; permissions 0775
> 
> MrMuscle:~ mnewman$ sudo port selfupdate
> --->  Updating MacPorts base sources using rsync
> MacPorts base version 2.5.4 installed,
> MacPorts base version 2.6.1 downloaded.
> --->  Updating the ports tree
> --->  MacPorts base is outdated, installing new version 2.6.1
> Installing new MacPorts release in /opt/local as root:wheel; permissions 0775
> 
> It seems that 2.6.1 never actually gets installed.

You're likely running into this bug:


Using the -v or -d flag to get more verbose output will show you what's
actually happening, e.g. 'sudo port -d selfupdate'.

- Josh


Re: snowleopardfixes is obsolete; please uninstall it.

2019-10-05 Thread Jeffrey Walton
Ok, thanks.

On Sat, Oct 5, 2019 at 8:19 PM Joshua Root  wrote:
>
> Jeffrey Walton wrote:
> > I'm trying to get an old PowerMac upgraded. I'm seeing the error
> > message below. Cat'ing the log, I can't tell which package I should
> > remove.
> >
> > What package should be removed?
>
> >   port upgrade outdated
> > --->  Configuring snowleopardfixes
> > Error: snowleopardfixes is obsolete; please uninstall it.
> > Error: Failed to configure snowleopardfixes: obsolete port
>
> The port in question is literally called 'snowleopardfixes'. The
> maintainer should have marked it as replaced by legacy-support; I've
> just done so.
>
> - Josh


Re: snowleopardfixes is obsolete; please uninstall it.

2019-10-05 Thread Joshua Root
Jeffrey Walton wrote:
> I'm trying to get an old PowerMac upgraded. I'm seeing the error
> message below. Cat'ing the log, I can't tell which package I should
> remove.
> 
> What package should be removed?

>   port upgrade outdated
> --->  Configuring snowleopardfixes
> Error: snowleopardfixes is obsolete; please uninstall it.
> Error: Failed to configure snowleopardfixes: obsolete port

The port in question is literally called 'snowleopardfixes'. The
maintainer should have marked it as replaced by legacy-support; I've
just done so.

- Josh


sudo port selfupdate Doesn't Seem To Work

2019-10-05 Thread Michael Newman via macports-users
What’s going on here?

--->  Updating MacPorts base sources using rsync
MacPorts base version 2.5.4 installed,
MacPorts base version 2.6.1 downloaded.
--->  Updating the ports tree
--->  MacPorts base is outdated, installing new version 2.6.1
Installing new MacPorts release in /opt/local as root:wheel; permissions 0775

MrMuscle:~ mnewman$ sudo port selfupdate
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.5.4 installed,
MacPorts base version 2.6.1 downloaded.
--->  Updating the ports tree
--->  MacPorts base is outdated, installing new version 2.6.1
Installing new MacPorts release in /opt/local as root:wheel; permissions 0775

It seems that 2.6.1 never actually gets installed.

snowleopardfixes is obsolete; please uninstall it.

2019-10-05 Thread Jeffrey Walton
Hi Everyone,

I'm trying to get an old PowerMac upgraded. I'm seeing the error
message below. Cat'ing the log, I can't tell which package I should
remove.

What package should be removed?

Thanks in advance.

= Terminal commands =

root# port selfupdate && port upgrade outdated && port clean inactive
&&  port -f uninstall inactive
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.6.1 installed,
MacPorts base version 2.6.1 downloaded.
--->  Updating the ports tree
--->  MacPorts base is already the latest version

= Terminal Output =

The ports tree has been updated. To upgrade your installed ports, you should run
  port upgrade outdated
--->  Configuring snowleopardfixes
Error: snowleopardfixes is obsolete; please uninstall it.
Error: Failed to configure snowleopardfixes: obsolete port
Error: See 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_snowleopardfixes/snowleopardfixes/main.log
for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

= Log file =

root# cat 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_snowleopardfixes/snowleopardfixes/main.log
version:1
:debug:sysinfo Mac OS X 10.5 (darwin/9.8.0) arch powerpc
:debug:sysinfo MacPorts 2.5.4
:debug:sysinfo Xcode 3.1.4
:debug:sysinfo SDK 10.5
:debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 10.5
:debug:clean snowleopardfixes has no conflicts
:debug:main Executing org.macports.main (snowleopardfixes)
:debug:main dropping privileges: euid changed to 507, egid changed to 500.
:debug:archivefetch archivefetch phase started at Sat Aug 10 03:24:42 EDT 2019
:debug:archivefetch Executing org.macports.archivefetch (snowleopardfixes)
:debug:archivefetch Privilege de-escalation not attempted as not
running as root.
:debug:fetch fetch phase started at Sat Aug 10 03:24:42 EDT 2019
:notice:fetch --->  Fetching distfiles for snowleopardfixes
:debug:fetch elevating privileges for fetch: euid changed to 0, egid
changed to 0.
:debug:fetch dropping privileges: euid changed to 507, egid changed to 500.
:debug:fetch Executing org.macports.fetch (snowleopardfixes)
:debug:fetch Privilege de-escalation not attempted as not running as root.
:debug:checksum checksum phase started at Sat Aug 10 03:24:42 EDT 2019
:notice:checksum --->  Verifying checksums for snowleopardfixes
:debug:checksum Executing org.macports.checksum (snowleopardfixes)
:debug:checksum Privilege de-escalation not attempted as not running as root.
:debug:extract extract phase started at Sat Aug 10 03:24:43 EDT 2019
:notice:extract --->  Extracting snowleopardfixes
:debug:extract Executing org.macports.extract (snowleopardfixes)
:debug:extract Privilege de-escalation not attempted as not running as root.
:debug:patch patch phase started at Sat Aug 10 03:24:43 EDT 2019
:debug:patch Executing org.macports.patch (snowleopardfixes)
:debug:patch Privilege de-escalation not attempted as not running as root.
:debug:configure configure phase started at Sat Aug 10 03:24:43 EDT 2019
:notice:configure --->  Configuring snowleopardfixes
:debug:configure Preferred compilers: gcc-4.2 apple-gcc-4.2 gcc-4.0
macports-clang-3.4 macports-clang-3.3
:debug:configure Using compiler 'Xcode GCC 4.2'
:debug:configure Executing proc-pre-org.macports.configure-configure-0
:error:configure snowleopardfixes is obsolete; please uninstall it.
:error:configure Failed to configure snowleopardfixes: obsolete port
:debug:configure Error code: NONE
:debug:configure Backtrace: obsolete port
:debug:configure while executing
:debug:configure "$pre $targetname"
:error:configure See
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_snowleopardfixes/snowleopardfixes/main.log
for details.
version:1
:debug:sysinfo Mac OS X 10.5 (darwin/9.8.0) arch powerpc
:debug:sysinfo MacPorts 2.6.1
:debug:sysinfo Xcode 3.1.4
:debug:sysinfo SDK 10.5
:debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 10.5
:debug:clean snowleopardfixes has no conflicts
:debug:main Executing org.macports.main (snowleopardfixes)
:debug:main dropping privileges: euid changed to 507, egid changed to 500.
:debug:main Skipping completed org.macports.archivefetch (snowleopardfixes)
:debug:main Privilege de-escalation not attempted as not running as root.
:debug:main Skipping completed org.macports.fetch (snowleopardfixes)
:debug:main Privilege de-escalation not attempted as not running as root.
:debug:main Skipping completed org.macports.checksum (snowleopardfixes)
:debug:main Privilege de-escalation not attempted as not running as root.
:debug:main Skipping completed org.macports.extract (snowleopardfixes)
:debug:main Privilege de-escalation not attempted as not running as root.
:debug:main Skipping completed org.macports.patch (snowleopardfixes)
:debug:main Privilege de-escalation not attempted as not running as root.
:debug:configure configure 

Re: dependency on correct openssl?

2019-10-05 Thread Richard L. Hamilton
No, I'd just run
port echo rdepends:vde2
and noticed virtualbox and a couple of related sub-ports in the output.

Still, I gather one could also use vde2 with some builds of QEMU, for example.  
So it presumably still has its uses, esp. since it can apparently optionally 
apply degrees of network impairment, perhaps useful for testing network stack 
or network server or client application robustness without expensive test 
hardware.

I'm not sure why I have vde2 installed, actually.  I might have been thinking 
of building something that required it (not necessarily something in MacPorts), 
but I don't recall what that might be.  I recall having some interest in 
getting hercules with bridged networking to work (both with the host and out to 
the internet) even if only WiFi and not Ethernet was in use (ISTR that local to 
the host didn't work with only WiFi and their implementation of bridging, but I 
could be misremembering); but hercules doesn't seem to have any need or option 
for vde2, so that probably wasn't it.


> On Oct 5, 2019, at 14:39, Ken Cunningham  
> wrote:
> 
> Oh, gosh -- our virtualbox port is so old and out of date I wouldn't even 
> consider using it.
> 
> it should probably be removed, I guess. 
> 
> Do you actually have it installed? I am startled if so !
> 
> 
> Ken
> 
> 
> 
> 
> On 2019-10-05, at 11:08 AM, Richard L. Hamilton wrote:
> 
>> Thank you! From the tickets you filed, it certainly looks like you did a 
>> thorough job of investigating and reporting the issues.  Hopefully they'll 
>> get to it reasonably soon, although clearly that's beyond your control.
>> 
>> Given that virtualbox depends on it (at least if the vde2 variant is 
>> enabled), I was surprised that it has such issues left unresolved.  But in
>> https://www.virtualbox.org/manual/ch06.html#network_vde 
>> 
>> I see "At the moment this option requires compilation of Oracle VM 
>> VirtualBox from sources, as the Oracle packages do not include it."  So I 
>> guess the folks with commercial resources also just avoided that.
>> 
>> Would it be a good idea, until vde2 is working again (not that it would help 
>> anyone with the virtualbox port already installed), to have it not be a 
>> default variant for the virtualbox port? (that's how I read [+]vde2 in the 
>> output of port info virtualbox)
>> 
>>> On Oct 5, 2019, at 09:21, Ryan Schmidt >> > wrote:
>>> 
>>> 
>>> 
>>> On Oct 4, 2019, at 21:41, Richard L. Hamilton wrote:
>>> 
 I see that kdelibs4 and xmms2 are ok now; thanks to whoever did that (esp. 
 kdelibs4, which is probably nasty to maintain).
 
 The one I have left that means I can't just "port upgrade outdated" on my 
 system with the most packages installed, running the current (Mojave) OS, 
 is vde2; a look at the log file makes it appear quite likely that's also 
 an openssl changeover related problem.
>>> 
>>> I looked into vde2 a few days ago.
>>> 
>>> It is not compatible with openssl 1.1, as you found.
>>> 
>>> There is a newer version than the one we have in the port available, but it 
>>> is years old and is also still not openssl 1.1 compatible.
>>> 
>>> This has been reported to the developers. Their response was to change 
>>> their code so that it uses wolfssl instead of openssl. They have not yet 
>>> released a new version containing this change.
>>> 
>>> I tried to update the port to the latest released version and backport the 
>>> wolfssl change. Just getting that patch to apply required me to backport a 
>>> number of other changes as well, and I don't think I ended up with a 
>>> successful build after that either.
>>> 
>>> In the process, I noticed a half dozen other problems with their code. I 
>>> reported these to the developers. I was intending to wait for them to 
>>> acknowledge and hopefully fix those issues and release a new stable version 
>>> so that I could then update the port to that version but so far they have 
>>> not responded to those reports.
>>> 
>>> https://github.com/virtualsquare/vde-2/issues 
>>> 
>>> 
>>> 
>>> 
>> 
> 



Re: dependency on correct openssl?

2019-10-05 Thread Ken Cunningham
Oh, gosh -- our virtualbox port is so old and out of date I wouldn't even 
consider using it.

it should probably be removed, I guess. 

Do you actually have it installed? I am startled if so !


Ken




On 2019-10-05, at 11:08 AM, Richard L. Hamilton wrote:

> Thank you! From the tickets you filed, it certainly looks like you did a 
> thorough job of investigating and reporting the issues.  Hopefully they'll 
> get to it reasonably soon, although clearly that's beyond your control.
> 
> Given that virtualbox depends on it (at least if the vde2 variant is 
> enabled), I was surprised that it has such issues left unresolved.  But in
> https://www.virtualbox.org/manual/ch06.html#network_vde
> I see "At the moment this option requires compilation of Oracle VM VirtualBox 
> from sources, as the Oracle packages do not include it."  So I guess the 
> folks with commercial resources also just avoided that.
> 
> Would it be a good idea, until vde2 is working again (not that it would help 
> anyone with the virtualbox port already installed), to have it not be a 
> default variant for the virtualbox port? (that's how I read [+]vde2 in the 
> output of port info virtualbox)
> 
>> On Oct 5, 2019, at 09:21, Ryan Schmidt  wrote:
>> 
>> 
>> 
>> On Oct 4, 2019, at 21:41, Richard L. Hamilton wrote:
>> 
>>> I see that kdelibs4 and xmms2 are ok now; thanks to whoever did that (esp. 
>>> kdelibs4, which is probably nasty to maintain).
>>> 
>>> The one I have left that means I can't just "port upgrade outdated" on my 
>>> system with the most packages installed, running the current (Mojave) OS, 
>>> is vde2; a look at the log file makes it appear quite likely that's also an 
>>> openssl changeover related problem.
>> 
>> I looked into vde2 a few days ago.
>> 
>> It is not compatible with openssl 1.1, as you found.
>> 
>> There is a newer version than the one we have in the port available, but it 
>> is years old and is also still not openssl 1.1 compatible.
>> 
>> This has been reported to the developers. Their response was to change their 
>> code so that it uses wolfssl instead of openssl. They have not yet released 
>> a new version containing this change.
>> 
>> I tried to update the port to the latest released version and backport the 
>> wolfssl change. Just getting that patch to apply required me to backport a 
>> number of other changes as well, and I don't think I ended up with a 
>> successful build after that either.
>> 
>> In the process, I noticed a half dozen other problems with their code. I 
>> reported these to the developers. I was intending to wait for them to 
>> acknowledge and hopefully fix those issues and release a new stable version 
>> so that I could then update the port to that version but so far they have 
>> not responded to those reports.
>> 
>> https://github.com/virtualsquare/vde-2/issues
>> 
>> 
>> 
> 



Re: dependency on correct openssl?

2019-10-05 Thread Richard L. Hamilton
Thank you! From the tickets you filed, it certainly looks like you did a 
thorough job of investigating and reporting the issues.  Hopefully they'll get 
to it reasonably soon, although clearly that's beyond your control.

Given that virtualbox depends on it (at least if the vde2 variant is enabled), 
I was surprised that it has such issues left unresolved.  But in
https://www.virtualbox.org/manual/ch06.html#network_vde 

I see "At the moment this option requires compilation of Oracle VM VirtualBox 
from sources, as the Oracle packages do not include it."  So I guess the folks 
with commercial resources also just avoided that.

Would it be a good idea, until vde2 is working again (not that it would help 
anyone with the virtualbox port already installed), to have it not be a default 
variant for the virtualbox port? (that's how I read [+]vde2 in the output of 
port info virtualbox)

> On Oct 5, 2019, at 09:21, Ryan Schmidt  wrote:
> 
> 
> 
> On Oct 4, 2019, at 21:41, Richard L. Hamilton wrote:
> 
>> I see that kdelibs4 and xmms2 are ok now; thanks to whoever did that (esp. 
>> kdelibs4, which is probably nasty to maintain).
>> 
>> The one I have left that means I can't just "port upgrade outdated" on my 
>> system with the most packages installed, running the current (Mojave) OS, is 
>> vde2; a look at the log file makes it appear quite likely that's also an 
>> openssl changeover related problem.
> 
> I looked into vde2 a few days ago.
> 
> It is not compatible with openssl 1.1, as you found.
> 
> There is a newer version than the one we have in the port available, but it 
> is years old and is also still not openssl 1.1 compatible.
> 
> This has been reported to the developers. Their response was to change their 
> code so that it uses wolfssl instead of openssl. They have not yet released a 
> new version containing this change.
> 
> I tried to update the port to the latest released version and backport the 
> wolfssl change. Just getting that patch to apply required me to backport a 
> number of other changes as well, and I don't think I ended up with a 
> successful build after that either.
> 
> In the process, I noticed a half dozen other problems with their code. I 
> reported these to the developers. I was intending to wait for them to 
> acknowledge and hopefully fix those issues and release a new stable version 
> so that I could then update the port to that version but so far they have not 
> responded to those reports.
> 
> https://github.com/virtualsquare/vde-2/issues
> 
> 
> 



Re: mpkg package variants

2019-10-05 Thread Werner LEMBERG


>> Let me reformulate my question: Does the way how I have installed
>> MacPorts packages on my computer influence how `port mpkg' works
>> for a given package?  Given that `port mpkg' rebuilds all packages,
>> I would expect no.  Instead, I would expect some control file (or a
>> special command line sequence) to control variants of package
>> dependencies.
> 
> I believe you can just specify the variants that you want (for the
> port and all of its dependencies) at the command line when you run
> `port mpkg`, can't you?  As in:
> 
>   sudo port mpkg lilypond-devel +mactex +perl5_28

This seems to work, thanks!  Maybe it's worth to document that.

Of course, the next question is whether MacPorts variant strings form
a consistent set without contradictions.

Another issue: There are many files in the mpkg file that are
definitely unnecessary to run the final program (in my case the
`lilypond' binary from `lilypond-devel'), for example test files for
python, or header files of C libraries, or (most of the)
documentation.  Is there any support from `port' to not package that?


Werner


Re: linker (?) issues on 10.5 with gcc (cmake/TenFourFox)

2019-10-05 Thread Ken Cunningham
> I think the changes to the cctools port are calling in a different assembler 
> now, not the old gas assembler that previously would be used.
> 
> I can check for you.
> 
> I forget if we still have a way to force gas to be used. I think we do, with 
> -Wa,-q or similar.



Yes, I changed my build line in my (local) tenfourfox port to force the 
traditional gas assembler like this:


export CC="/opt/local/bin/gcc-mp-4.8 -Wa,-Q -flax-vector-conversions -O3 -m32 
-read_only_relocs suppress"
export CXX="/opt/local/bin/g++-mp-4.8 -Wa,-Q -flax-vector-conversions 
-fpermissive -O3 -m32 -read_only_relocs suppress"



Re: linker (?) issues on 10.5 with gcc (cmake/TenFourFox)

2019-10-05 Thread Ken Cunningham
I think the changes to the cctools port are calling in a different assembler 
now, not the old gas assembler that previously would be used.

I can check for you.

I forget if we still have a way to force gas to be used. I think we do, with 
-Wa,-q or similar.

K 


Re: dependency on correct openssl?

2019-10-05 Thread Ryan Schmidt



On Oct 4, 2019, at 21:41, Richard L. Hamilton wrote:

> I see that kdelibs4 and xmms2 are ok now; thanks to whoever did that (esp. 
> kdelibs4, which is probably nasty to maintain).
> 
> The one I have left that means I can't just "port upgrade outdated" on my 
> system with the most packages installed, running the current (Mojave) OS, is 
> vde2; a look at the log file makes it appear quite likely that's also an 
> openssl changeover related problem.

I looked into vde2 a few days ago.

It is not compatible with openssl 1.1, as you found.

There is a newer version than the one we have in the port available, but it is 
years old and is also still not openssl 1.1 compatible.

This has been reported to the developers. Their response was to change their 
code so that it uses wolfssl instead of openssl. They have not yet released a 
new version containing this change.

I tried to update the port to the latest released version and backport the 
wolfssl change. Just getting that patch to apply required me to backport a 
number of other changes as well, and I don't think I ended up with a successful 
build after that either.

In the process, I noticed a half dozen other problems with their code. I 
reported these to the developers. I was intending to wait for them to 
acknowledge and hopefully fix those issues and release a new stable version so 
that I could then update the port to that version but so far they have not 
responded to those reports.

https://github.com/virtualsquare/vde-2/issues