Re: Problems with our libgcc_s.so in base [FYI: armv6 C++/g++6 example under stable/11 -r304029]

2016-08-21 Thread Mark Millard 
"problems come when we try to us archtiectures not fully supported by out 
libgcc_s.so" ( from https://people.freebsd.org/~db/libgcc.txt ). . .

On armv6 (an rpi2) C++ by itself can have /lib/libgcc_s.so.1 not being 
sufficient, for example with g++6 being used: 

> # g++6 -std=c++14 -O2 cpp_clocks_investigation.cpp
> # ldd a.out
> a.out:
> libstdc++.so.6 => /usr/local/lib/gcc6/libstdc++.so.6 (0x2010)
> libm.so.5 => /lib/libm.so.5 (0x20053000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x20076000)
> libc.so.7 => /lib/libc.so.7 (0x2030)
> # ./a.out
> /usr/local/lib/gcc6/libstdc++.so.6: Undefined symbol "__aeabi_uldivmod"

By contrast:

> # g++6 -Wl,-rpath=/usr/local/lib/gcc6 -std=c++14 -O2 
> cpp_clocks_investigation.cpp
> # ldd a.out
> a.out:
> libstdc++.so.6 => /usr/local/lib/gcc6/libstdc++.so.6 (0x2010)
> libm.so.5 => /lib/libm.so.5 (0x20053000)
> libgcc_s.so.1 => /usr/local/lib/gcc6/libgcc_s.so.1 (0x20076000)
> libc.so.7 => /lib/libc.so.7 (0x2030)
> # ./a.out
> std::numeric_limits::max(): 9'223'372'036'854'775'807
. . . (works fine) . . .


Context details:

> # svnlite info /usr/src/ | grep "Re[vl][ia:]"
> Relative URL: ^/stable/11
> Revision: 304029
> Last Changed Rev: 304029

> # uname -apKU
> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #4 r304029M: Sat Aug 13 
> 01:10:34 PDT 2016 
> markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-N
> ODBG  arm armv6 1100500 1100500


===
Mark Millard
markmi at dsl-only.net

___
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"

Re: Needed committer, multimedia/zoneminder forgotten again :(

2016-08-21 Thread Chris Rees 
Done.

Chris

On 21 August 2016 19:40:40 BST, abi  wrote:
>Hello,
>
>can anyone commit 
>https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211681 ?
>This fixes build under CURRENT.
>___
>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"
>
>
>-- 
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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"

Re: iso-codes

2016-08-21 Thread Koop Mast 
On Mon, 2016-08-22 at 02:42 +1000, Kubilay Kocak wrote:
> On 21/08/2016 8:49 PM, l...@lena.kiev.ua wrote:
> > 
> > Does the latest version of the port misc/iso-codes really need
> > python 3
> > for build?
> > 
> > Python 2.7 not enough?
> > 
> > https://svnweb.freebsd.org/ports/head/misc/iso-codes/Makefile?r1=40
> > 9133=420522
> A grep of the sources shows many references to python3 (calling
> script),
> including:

I think Lena is more wondering about the new build requirement off
python3. As your pointed out the scripts require python3, there is not
much I can do about that.

I also don't see much point in trying to bash the scripts into shape
using the full version (3.4 in this case) python version since they are
only used during build time.

-Koop

> bin/validate_json_data.py:#!/usr/bin/env python3
> bin/xml_from_json.py:#!/usr/bin/env python3
> bin/pot_from_json.py:#!/usr/bin/env python3
> bin/check_valid_utf8.py:#!/usr/bin/env python3
> 
> And in the build system:
> 
> common.mk:  python3 $(top_srcdir)/bin/pot_from_json.py $(DOMAIN)
> $(top_srcdir)/data
> common.mk:  python3 $(top_srcdir)/bin/xml_from_json.py $(DOMAIN)
> $(top_srcdir)/data $@
> common.mk:  python3 $(top_srcdir)/bin/check_valid_utf8.py
> $(pofiles)
> 
> I didn't check whether this was a recent change (new in 3.69) or not.
> 
> These could/should be updated to use python3.x scripts directly
> instead,
> rather then the python3 symlink provided by lang/python3. This could
> be
> done with judicious use of USES=shebangfix
> 
> Maintainer CC'd
> 
> Hope that helps Lena
> 
> ./koobs
___
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"

Needed committer, multimedia/zoneminder forgotten again :(

2016-08-21 Thread abi 

Hello,

can anyone commit 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211681 ?

This fixes build under CURRENT.
___
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"

Re: iso-codes

2016-08-21 Thread Kubilay Kocak 
On 21/08/2016 8:49 PM, l...@lena.kiev.ua wrote:
> Does the latest version of the port misc/iso-codes really need python 3
> for build?
> 
> Python 2.7 not enough?
> 
> https://svnweb.freebsd.org/ports/head/misc/iso-codes/Makefile?r1=409133=420522

A grep of the sources shows many references to python3 (calling script),
including:

bin/validate_json_data.py:#!/usr/bin/env python3
bin/xml_from_json.py:#!/usr/bin/env python3
bin/pot_from_json.py:#!/usr/bin/env python3
bin/check_valid_utf8.py:#!/usr/bin/env python3

And in the build system:

common.mk:  python3 $(top_srcdir)/bin/pot_from_json.py $(DOMAIN)
$(top_srcdir)/data
common.mk:  python3 $(top_srcdir)/bin/xml_from_json.py $(DOMAIN)
$(top_srcdir)/data $@
common.mk:  python3 $(top_srcdir)/bin/check_valid_utf8.py $(pofiles)

I didn't check whether this was a recent change (new in 3.69) or not.

These could/should be updated to use python3.x scripts directly instead,
rather then the python3 symlink provided by lang/python3. This could be
done with judicious use of USES=shebangfix

Maintainer CC'd

Hope that helps Lena

./koobs
___
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"

Re: Problems with out libgcc_s.so in base

2016-08-21 Thread Diane Bruce 
On Sun, Aug 21, 2016 at 03:37:58PM +0930, Shane Ambler wrote:
> On 20/08/2016 21:30, Diane Bruce wrote:
> > On Sat, Aug 20, 2016 at 03:04:44PM +0930, Shane Ambler wrote:
> >> On 19/08/2016 10:13, Steven G. Kargl wrote:
> > ...
> >> You should find that all newer copies of libgcc_s contain compatibility
> >> support for binaries that were linked to earlier versions.
> >>
> >
...
> 
> Actually the problem is going the other way. A port gets compiled and
> linked against the newer libs but at run time it finds the base system


*sigh* No.

> lib first and loads that which doesn't support the binary that is being
> run. If the gcc6 libgcc_s was always installed and found first then we
> wouldn't have this problem.

That's exactly what the -Wl,rpath=/usr/local/lib/lib is supposed to
do. 

Look at 
/usr/ports/Mk/Uses/gfortran.mk

FFLAGS+=-Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
FCFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
LDFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
-L${LOCALBASE}/lib/gcc${_GCC_VER} -B${LOCALBASE}/bin  

Any use of GCC to compile a port *SHOULD* have the same -rpath
otherwise it gets linked with our base libgcc_s which is *harmless*
99% of the time. The cases where it isn't are outlined here:
https://people.freebsd.org/~db/libgcc.txt

Your problem is cmake here.

>From blender Makefile

USES=   cmake:outsource compiler:features desktop-file-utils \
jpeg python:3.5 shebangfix

Look at this PR
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=20812

What happens is cmake strips the necessary rpath when it installs
the final binary.

This hack:
add to CMAKE_ARGS 
-DCMAKE_INSTALL_RPATH:STRING="${LOCALBASE}/lib/gcc${_GCC_VER}"

Will tell cmake to not strip the necessary gcc rpath information.
BTW I'd be interested if this fixed blender for you.

However, if this is the way to fix these problems, then it should
be documented or fixed cmake. However a naive non ports infrastructure build
using gcc/gfortran or cmake will still run into these problems.

> 
> I first found this issue trying to import numpy into blender. As blender
> had started and was using the base libgcc_s, when I tried to import
> numpy that needed the newer libgcc_s for it's fortran code it failed. I
> discovered that setting LD_LIBRARY_PATH in the environment when starting
> blender got it to load the newer libgcc_s which then worked when

Yes. Or a LD_PRELOAD (man rtld)

The stanza added in the ports infrastructure is a kludge added to
work around our out of date base libgcc_s.so


> importing numpy, so I've been happy doing that for a couple of years.

This is exactly the sort of bugs that have been reported in the ports
system for years.

> 
> I have seen the same thing were a python module has brought in the base
> libgcc_s before numpy which needed the newer one. The dynamic loading of
> python modules seems to be the only time I have seen this. Either
> changing the import order or LD_LIBRARY_PATH to get the newer lib loaded
> the first time has solved the issue.

Yep. You are SOL if your base program does not have a -rpath linking
/usr/local/lib libgcc_s first. (BTW A LD_PRELOAD will fix your
problem here as it forces the port libgcc_s to be already loaded
before rtld has to search for it. It will satisfy the linking requirements
without messing around with LD_LIBRARY_PATH) Any program that does
a dlopen then requiring a ports libgcc_s will also fail, not just
python.

> 
> So one solution could be to copy the newer libgcc_s into /lib but the
> newer library won't get added to base as it contains GPLv3 code. Maybe 
> remove /lib/libgcc_s.so to force the search for a newer version.

If you read my original post. (Did you read it?) That's exactly what
I suggest. We should rename it to libcc_s.so 

...
> -- 
> FreeBSD - the place to B...Software Developing
> 
> Shane Ambler
> 
> 

Diane Bruce (Getting tired and testy at explaining this bug 1000 times)
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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"

Re: php7-extensions PDF (PECL-PDFLIB) fails

2016-08-21 Thread Matthew Seaman 
On 21/08/2016 11:27, Andy Wodfer wrote:
> I recently upgraded to 10.3 REL on a test server. I'm trying to install all
> the latest versions for Apache, mysql, php and so on.
> 
> php7 is installed and works perfectly with apache. However, I couldn't
> install the extension pecl-pdflib from the php7 extensions port, it fails
> with the message doesn't supprt php7.
> 
> ===>   phpMyAdmin-4.6.0 depends on file: 
> /usr/local/lib/php/20151012/openssl.so
> - found
> ===>   Returning to build of phpMyAdmin-4.6.0
> ===>   phpMyAdmin-4.6.0 depends on file: /usr/local/lib/php/20151012/pdf.so
> - not found
> ===>  pecl-pdflib-3.0.4 cannot be installed: doesn't work with lang/php70
> port (doesn't support PHP 70).
> *** Error code 1
> 
> Stop.
> make[2]: stopped in /usr/ports/print/pecl-pdflib
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/ports/databases/phpmyadmin
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/databases/phpmyadmin
> 
> I need this extension to create PDF files from an application my client is
> running. Anyone?

Ah, so you definitely need the pdflib extension?  That means your only
option here is to downgrade to php-5.6 I'm afraid.  (Otherwise you could
simply have dropped the PDF support from phpMyAdmin.)

Hmmm... it's odd that there's apparently no fix freely available to make
pecl-pdflib work with php-7 by this late date.  There is apparently
something commercially available from the pdflib people themselves, but
obviously, you have to pay for that:

https://www.pdflib.com/fileadmin/pdflib/System_Requirements/PDFlib-9.0.7-system-requirements.txt

Also, no idea if phpMyAdmin can use the PHP bindings there.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Re: graphics/gd marked as broken?

2016-08-21 Thread Grzegorz Junka 



On 21/08/2016 04:31, Shane Ambler wrote:

On 21/08/2016 04:46, Grzegorz Junka wrote:


On 20/08/2016 19:11, Grzegorz Junka wrote:


On 20/08/2016 16:23, Walter Schwarzenfeld wrote:

The port is not broken, it compiles in port and with poudriere.
Only if option WEBP is set to on  it is broken.

look with

poudriere options -C -jhailname graphics/gd

how is it set, and change it if is to on.


So, poudriere lies then, it says it's broken:

[00:01:21] >> [04][00:00:00] Starting build of graphics/gd
[00:01:21] >> [04][00:00:00] Finished build of graphics/gd:
Ignored: is marked as broken: circular dependencies

Greg


Sorry, I should have been clearer. I know the port isn't broken, I just
don't understand why poudriere says it's marked as broken if, according
to you, it's a circular dependency and the port isn't marked in any way?
Greg


Actually it isn't poudriere - the port itself says it's broken when the
WEBP option is enabled.

WEBP_BROKEN=circular dependencies

So the new version of gd added support for webp, the maintainer added
the option to enable it, then marked the option as broken.

gd doesn't have WEBP enabled by default so you have settings somewhere
to enable it. If you aren't specifically enabling the WEBP option for
gd then check that you aren't enabling it globally in OPTIONS_SET

In the make.conf for your build add -
graphics_gd_UNSET= WEBP

If that doesn't work some others to try.
graphics_gd_UNSET_FORCE= WEBP
OPTIONS_UNSET=WEBP
OPTIONS_UNSET_FORCE=WEBP



Thanks Shane. I actually enabled the option in graphics/gd and it was 
working fine. It only broke after an update the the ports tree. I had it 
enabled in many other packages so didn't think it might be a problem. 
Disabling the option makes the error go away and poudriere now is able 
to compile gd. I didn't know a maintainer can mark a port as broken only 
if a particular option is enabled, I thought that the whole port is 
either marked as broken or not.

Greg
___
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"

Re: mail/rainloop needs a committer

2016-08-21 Thread Kurt Jaeger 
Hi!

> I validated a good diff for mail/rainloop, can a commiter push it to
> ports tree ?
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211870

Done.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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"

Can a commiter look at devel/godot

2016-08-21 Thread Shane Ambler 


After several changes over the last few months it would be nice if the
update to devel/godot and the new devel/godot-tools could get committed.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209742

Thanks

--
FreeBSD - the place to B...Software Developing

Shane Ambler

___
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"

Re: Problems with out libgcc_s.so in base

2016-08-21 Thread Shane Ambler 

On 20/08/2016 21:30, Diane Bruce wrote:

On Sat, Aug 20, 2016 at 03:04:44PM +0930, Shane Ambler wrote:

On 19/08/2016 10:13, Steven G. Kargl wrote:

...

You should find that all newer copies of libgcc_s contain compatibility
support for binaries that were linked to earlier versions.



Indeed. And the version masquerading as a GNU libgcc_s in base
does the same thing. Two problems: our base libgcc_s only covers version up
to GCC_4.2.0 and there is a name conflict on the library name with
libgcc_s from the gnu compiler. Hence if a program links against base
libgcc_s first then requires libgfortran which itself requires support
for above GCC_4.2.0, the program fails. OR Whenever a program requires
support that is missing on the platform it is running on from our
libgcc_s, it will fail.

There are numerous PR's on this which all have the common problem
of linking with a libgcc_s that does not support > GCC_4.2.0


Actually the problem is going the other way. A port gets compiled and
linked against the newer libs but at run time it finds the base system
lib first and loads that which doesn't support the binary that is being
run. If the gcc6 libgcc_s was always installed and found first then we
wouldn't have this problem.

I first found this issue trying to import numpy into blender. As blender
had started and was using the base libgcc_s, when I tried to import
numpy that needed the newer libgcc_s for it's fortran code it failed. I
discovered that setting LD_LIBRARY_PATH in the environment when starting
blender got it to load the newer libgcc_s which then worked when
importing numpy, so I've been happy doing that for a couple of years.

I have seen the same thing were a python module has brought in the base
libgcc_s before numpy which needed the newer one. The dynamic loading of
python modules seems to be the only time I have seen this. Either
changing the import order or LD_LIBRARY_PATH to get the newer lib loaded
the first time has solved the issue.

So one solution could be to copy the newer libgcc_s into /lib but the
newer library won't get added to base as it contains GPLv3 code. Maybe 
remove /lib/libgcc_s.so to force the search for a newer version.


While bug reports have lead to other things, I think the solution might
be to configure/patch ld to get it searching paths to find the newer
version first. libgcc_s would be such a common case that we could have a
permanent ld setting in base to always find a newer libgcc_s before the
base version. I haven't been bitten enough to have looked at this.

--
FreeBSD - the place to B...Software Developing

Shane Ambler

___
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"