Re: quirk in libpng16.{a|so}

2020-07-14 Thread Don Wilde


On 7/14/20 10:10 AM, y...@freebsd.org wrote:

On 2020-07-14 09:59, Don Wilde wrote:
Hi, Yuri -- I understand that you maintain the png++ "C++ wrapper for 
libpng"?


There's a game engine I'm trying to work with on my 12-stable system, 
called Drag[en]gine.


https://dragondreams.ch/

It's a complicated port, and I'll end up tweaking some heavy-duty 
OpenGL graphics to get it to do stuff for me. The first issue is that 
our libpng16 library is missing a C++ call: 
png_access_version_number(), which causes its setup program (a Python 
script)to crash.


I have both png and png++ installed and both libpng16.so and 
libpng16.a are present.


I'm in the process of (also) installing it on my Ubuntu 18.04.4 
machine. It hasn't given me this libpng16 issue.


What do you think of this problem? Is this yours or is it the actual 
libpng library itself?




Hi Don,


I used png++ on both Linux (CentOS) and FreeBSD without any problems.


I also can't find png_access_version_number() call in the png++ sources.


Okay, this must actually be a call in the actual libpng sources.




Could you please provide an example code that exhibits the problem?


Here's what happens, though there's evidently quite a bit of 
construction that happens in the middle.


scons is Yet Another Super-Make, and it's plus (evidently) is that it 
can also generate Android and Windows code.


I type 'scons -h', and the output is:
scons: Reading SConscript files ...
Checking for zlibVersion() in C++ library z... yes
Checking for png_access_version_number() in C++ library png16... no
KeyError: 'forceRuntimeLibs':
  File "/opt/dragengine/SConstruct", line 633:
    duplicate=0, exports='parent_env parent_targets parent_report' )
  File 
"/usr/local/lib/python3.7/site-packages/SCons/Script/SConscript.py", 
line 660:

    return method(*args, **kw)
  File 
"/usr/local/lib/python3.7/site-packages/SCons/Script/SConscript.py", 
line 597:

    return _SConscript(self.fs, *files, **subst_kw)
  File 
"/usr/local/lib/python3.7/site-packages/SCons/Script/SConscript.py", 
line 286:

    exec(compile(scriptdata, scriptname, 'exec'), call_stack[-1].globals)
  File "/opt/dragengine/extern/libpng/SConscript", line 120:
forceRuntimeLibs.extend(parent_targets['lib_zlib']['forceRuntimeLibs'])

The SConscript files are generated from the (attached) custom.py, from 
what I understand. The error happens in the construct between lines 631 
- 633 of that attached SConscript file (which acts like Makefile does 
for C and C++).


Don Wilde

* What is the Internet of Things but a system  *
* of systems including humans? *


from SConsCommon import *
from SConsPlatformAndroid import androidUpdateEnv

# create environment
tools = ARGUMENTS.get( 'tools', '' )
if tools:
if tools == 'mingw64':
parent_env = Environment( CPPPATH='.', LIBPATH='.', 
tools=['mingw'] )

compiler = 'x86_64-w64-mingw32'
if not parent_env.Detect( '{}-g++'.format( compiler ) ):
print( 'Windows 64-bit Cross-Compiler not found.' )
Return()

parent_env.Replace( CC = '{}-gcc'.format( compiler ) )
parent_env.Replace( CXX = '{}-g++'.format( compiler ) )
parent_env.Replace( LD = '{}-ld'.format( compiler ) )
parent_env.Replace( AR = '{}-ar'.format( compiler ) )
parent_env.Replace( STRIP = '{}-strip'.format( compiler ) )
#parent_env.Replace( MAKE = '{}-make'.format( compiler ) )
parent_env.Replace( RANLIB = '{}-ranlib'.format( compiler ) )
parent_env.Replace( NM = '{}-nm'.format( compiler ) )
parent_env.Replace( RC = '{}-windres'.format( compiler ) )
parent_env.Replace( DLLTOOL = '{}-dlltool'.format( compiler ) )

parent_env.Replace( SHCCFLAGS = [ '$CCFLAGS' ] ) # remove -fPIC 
if included. just to silence misleading warnings
parent_env.Replace( SHLIBPREFIX = '' ) # fix prefix since the 
environment is set up for unix
parent_env.Replace( SHLIBSUFFIX = '.dll' ) # fix suffix since 
the environment is set up for unix
parent_env.Replace( LIBPREFIX = '' ) # fix prefix since the 
environment is set up for unix
parent_env.Replace( LIBPREFIXES = [ '' ] ) # fix prefix since 
the environment is set up for unix
parent_env.Replace( LIBSUFFIX = '.lib' )
parent_env.Replace( LIBSUFFIXES = [ '.lib', '.a' ] )

parent_env[ 'OS_NAME' ] = 'win32'
parent_env[ 'SYS_PLATFORM' ] = 'win32'
parent_env[ 'CROSSCOMPILE_HOST' ] = compiler
parent_env[ 'CROSSCOMPILE_SYSROOT' ] = '/usr/{}'.format( 
compiler )
  

quirk in libpng16.{a|so}

2020-07-14 Thread Don Wilde
Hi, Yuri -- I understand that you maintain the png++ "C++ wrapper for 
libpng"?


There's a game engine I'm trying to work with on my 12-stable system, 
called Drag[en]gine.


https://dragondreams.ch/

It's a complicated port, and I'll end up tweaking some heavy-duty OpenGL 
graphics to get it to do stuff for me. The first issue is that our 
libpng16 library is missing a C++ call: png_access_version_number(), 
which causes its setup program (a Python script)to crash.


I have both png and png++ installed and both libpng16.so and libpng16.a 
are present.


I'm in the process of (also) installing it on my Ubuntu 18.04.4 machine. 
It hasn't given me this libpng16 issue.


What do you think of this problem? Is this yours or is it the actual 
libpng library itself?


--
Don Wilde

* What is the Internet of Things but a system  *
* of systems including humans? *


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: 12.1p7 no longer boots after doing zpool upgrade -a

2020-07-14 Thread John Kennedy
On Fri, Jul 10, 2020 at 02:25:02PM -0500, Kyle Evans wrote:
> >   So one recipe doesn't even seem to make the freebsd-boot partition, so is 
> > it
> > optional for a pure UEFI boot?  Should we always gpart-bootcode it if it 
> > exists
> > and upgrade BOOTx64.efi when the EFI partition exists, or is there a few 
> > more
> > wrinkles we need to worry about?
> 
> Correct, freebsd-boot is not needed for a pure UEFI boot. I wouldn't
> necessarily bother updating the freebsd-boot partition unless you
> suspect you may need to switch back to legacy boot at some point; UEFI
> is now rock-solid on all of my systems, so I've personally found no
> such need and on many of them I've removed the old freebsd-boot bits.
> 
> If you've got an ESP, you should update that manually. If you want to
> maintain the option of legacy boot, you should use gpart-bootcode for
> that but don't use it on the ESP with boot1.efifat.

  I don't know why I would.  Its pretty hard to find a non-UEFI motherboard
these days and, as you've said, it's been pretty solid.  I don't think I said
it initially, but this originally started off of 12.0 boot media (~2019/5/31),
rather than me partitioning it by hand or some more modern 12.1+ stick.

> >   In any case, is it a logical theory that my possible boot-order problem
> > is because drive order got swapped and maybe one wasn't properly updated?
> > They seem to be the same:
> >
> > # md5 /dev/nvd[01]p2
> > MD5 (/dev/nvd0p2) = 2ded438a2c97ea551446cc2d1d3b498e
> > MD5 (/dev/nvd1p2) = 2ded438a2c97ea551446cc2d1d3b498e
> >
> >   Ideally I'd like to have not boot through the UEFI boot menu every time.
> >
> >   I'm not sure why the drive order seems to matter right now.
> >
> 
> When you get booted back to the UEFI menu, is it a specific drive that
> you must select or do both equally work from that point?

  My options are basically M.2_1 and M.2_2 (not sure what labeled them, I think
that is the exact name, can confirm later).  #2 is currently the "first" drive,
and changing boot order in the BIOS to favor #1 doesn't seem to fix that.

  As I said, the motherboard died and the drives were moved to a new system
and I suspect that the order was swapped.  I never had a reason to question
my ability to boot from the 2nd disk, and hadn't done anything that merited
an upgrade that made me look at it this closely.

  Before I figured out what was going on, it would work some of the time.  I
suspect a race condition (where sometimes #1 would "win"), but I can't find
something that makes #2 a bad initial boot disk.  I don't see anything in
the boot messages that say which drive it had glommed onto.

  I can't say that I've tried to select #2.  I can try that later on today.
It's doing my weekly upgrade-build right now.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"