Re: [ports]: GH_TAGNAME: how to figure out this tagname on downloadable archives?

2017-10-16 Thread Yuri 

On 10/16/17 07:46, Mathieu Arnold wrote:

The first 7 digits may, or may not be sufficient. 7 is a magic number,
and should not be used. You should, instead, ask git directly what the
abbreviation should be with, for instance, `git log --abbrev-commit`.
It may give you a number that seven digits long, but it may very well
give you a longer one. I repeat, do not simply truncate a hash to its
first 7 digits, it may not be enough.


`git log --abbrev-commit` solution has two shortcomings. It only protects 
against preexisting hash collisions and not from future collisions. So, the 
port's fetch can still spontaneously fail in the future as a result of a future 
commit that introduces a collision. Secondly, it requires the manual clone of 
the repository which is inconvenient. IMO, it's more practical to just use 7 
digits, and switch to the full hash in an unlikely event when 7 digits fail. So 
far, this method virtually always worked.

Yuri

___
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: Using blaslapack

2017-10-16 Thread Diane Bruce 
On Mon, Oct 16, 2017 at 07:19:49AM -0700, Steve Kargl wrote:
> On Mon, Oct 16, 2017 at 02:18:01AM -0700, Yuri wrote:
> > On 10/15/17 23:20, Gleb Popov wrote:
> > > I've tracked these symbols to /usr/local/lib/gcc6/libgcc_s.so. But there 
> > > is
...
> > Fortran implementation based on gcc is faulty due to libgcc_s.so being 
> > present in 2 versions, in base and in gcc port, making any code 
> > containing both C++ and fortran impossible to run. Your application 
> > probably can't work on FreeBSD using gcc fortran for this reason.
> > 
> 
> Huh?  I use Netlib blas/lapack compiled with gfortran on FreeBSD
> with no problem.  If you're having problems with gfortran finding
> the right libgcc_s.so, then add -rpath /usr/local/lib/gcc5 (or gcc6
> or gcc7) to yout Fortran options.

Steve is correct IFF it's a simple program, but wrong if it is a module.
What has been biting us are interpreters (e.g. python) not linked
against gfortran with the right -rpath but linked against our native libgcc.
When a binary module is loaded bad things happen if module was built
with fortran. If it is known beforehand that such modules will be loaded then
the work around is to LD_PRELOAD the gfortran libgcc or use 
LD_LIBRARY_PATH to force the gfortran libgcc to be loaded first instead
of ours. The problem is figuring out which programs load such binary
modules in the first place. There are a myriad of proper fixes possible
including bringing our libgcc up to spec.

Incidentally, flang compiled modules are one possible fix but is limited
to amd64 at the moment. Do not mix gfortran and flang
compiled modules in one program if they use I/O. Of course they use
their own I/O routines. *sigh*

> Steve

Diane (looking for that pony still)
-- 
- 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"

Makefile cannot download from Sourceforge

2017-10-16 Thread blubee blubeeme 
I'm trying to download some files from sourceforge but it fails constantly.

PORTNAME= zipios++
PORTVERSION=  2.1.1
MASTER_SITES= SF/zipios/
DISTFILES=zipios-2.1.1.tar.gz

here's the output from trying to run make makesum

 sudo make makesum
=> zipios-2.1.1.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch
https://downloads.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch: https://downloads.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
https://cytranet.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch:
https://cytranet.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not
Found
=> Attempting to fetch
https://excellmedia.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch:
https://excellmedia.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
https://freefr.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch: https://freefr.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
https://jaist.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch: https://jaist.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
https://kent.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch: https://kent.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
https://nchc.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch: https://nchc.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
https://netcologne.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch:
https://netcologne.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
https://netix.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch: https://netix.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
https://superb-dca2.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch:
https://superb-dca2.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
https://superb-sea2.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch:
https://superb-sea2.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
https://ufpr.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch: https://ufpr.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
https://vorboss.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch: https://vorboss.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
http://downloads.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch: http://downloads.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
http://cytranet.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch: http://cytranet.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
http://excellmedia.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch:
http://excellmedia.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
http://freefr.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch: http://freefr.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
http://jaist.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch: http://jaist.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
http://kent.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch: http://kent.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
http://nchc.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch: http://nchc.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
http://netcologne.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch:
http://netcologne.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
http://netix.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch: http://netix.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
http://superb-dca2.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch:
http://superb-dca2.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
http://superb-sea2.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch:
http://superb-sea2.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
http://ufpr.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch: http://ufpr.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz:
Not Found
=> Attempting to fetch
http://vorboss.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz
fetch:

Re: Using blaslapack

2017-10-16 Thread Yuri 

On 10/16/17 07:19, Steve Kargl wrote:

Huh?  I use Netlib blas/lapack compiled with gfortran on FreeBSD
with no problem.  If you're having problems with gfortran finding
the right libgcc_s.so, then add -rpath /usr/local/lib/gcc5 (or gcc6
or gcc7) to yout Fortran options.



gfortran doesn't have a problem locating libgcc_s.so, Two libraries 
conflict, this is a problem.



Yuri

___
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: FreeBSD Port: windowmaker-0.95.8 - SOLVED

2017-10-16 Thread James Geering 
Hi Marco,
Thank you for your emails.  It is now working.
For some reason the /usr/local/include/ImageMagick-6/wand/ was sparsely
populated and the header file was not there.
So, I went into the /usr/ports/graphics/ImageMagick directory and issued
a 'make install' and realised that I hadn't
de-installed.  So then  'make deinstall' followed by a 'make reinstall'
and hey presto the ../include directory had
the header file in it.  I then moved to
the /usr/ports/x11-wm/windowmaker/ and tryied to 'make install.'  And it
worked,
it built fine and I can now run it.
I'm wondering why the header file wasn't there to start off with?  Is
because I had only used 'pkg install' and had not
built ImageMagick I wonder?
Many thanks,
James 

-Original Message-From: Marco Beishuizen 
Reply-to: Marco Beishuizen 
To: James Geering 
Cc: h...@freebsd.org, po...@freebsd.org
Subject: Re: FreeBSD Port: windowmaker-0.95.8
Date: Fri, 13 Oct 2017 20:42:05 +0200 (CEST)


On Fri, 13 Oct 2017, the wise James Geering wrote:

> After a few screens scrolling past the script stops with an error at 
> "checking for Magick support library ... configure: error: found 
> MagickWand library but could not compile its header"

..

> conftest.c:72:10: fatal error: 'wand/magick_wand.h' file not found

What happens if you try to install graphics/ImageMagick first? On my 
machine the header file is located in 
/usr/local/include/ImageMagick-6/wand/

Regards,
Marco

___
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: [ports]: GH_TAGNAME: how to figure out this tagname on downloadable archives?

2017-10-16 Thread Mathieu Arnold 
Le 15/10/2017 à 21:47, O. Hartmann a écrit :
> Am Sun, 15 Oct 2017 12:35:49 -0700
> Yuri  schrieb:
>
>> On 10/15/17 12:19, O. Hartmann wrote:
>>> Out of the blue there is a so called GH_TAGNAME. It reflects some late 
>>> commit/revision
>>> number on an archive. Now I try to figure out how to find such a 
>>> GH_TAGNAME. Since I
>>> do not push stuff to github, it is some new playfield and there might be an 
>>> easy way
>>> to figure out, but this way is obscured to me right now.  
>>
>> GH_TAGNAME is the git commit hash, a hexadecimal number. github shows them 
>> for every
>> commit. Usually, 7 first characters suffice. GH_TAGNAME overrides the port 
>> version when
>> tarball is fetched. Just copy and paste it. :-)
>>
>>
>> Yuri
>>
> Hello, thanks for your response,
>
> all right, that is what I picked up from the porter's handbook, but I must 
> have
> overlooked the note (if there is anything like that) regarding the sufficient 
> first 7
> digits.

The first 7 digits may, or may not be sufficient. 7 is a magic number,
and should not be used. You should, instead, ask git directly what the
abbreviation should be with, for instance, `git log --abbrev-commit`. 
It may give you a number that seven digits long, but it may very well
give you a longer one. I repeat, do not simply truncate a hash to its
first 7 digits, it may not be enough.

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: Using blaslapack

2017-10-16 Thread Steve Kargl 
On Mon, Oct 16, 2017 at 02:18:01AM -0700, Yuri wrote:
> On 10/15/17 23:20, Gleb Popov wrote:
> > I've tracked these symbols to /usr/local/lib/gcc6/libgcc_s.so. But there is
> > also /usr/lib/libgcc_s.so and it doesn't have such symbols. I suspect this
> > is the source of the error, but I wasn't able to fix it. Passing -Wl,-rpath
> > as advised by lang/gcc6 pkg-message doesn't help. The only workaround I
> > came up with is USE_GCC=yes to compile DLib itself, but that's pretty
> > unsatisfactory.
> 
> 
> Fortran implementation based on gcc is faulty due to libgcc_s.so being 
> present in 2 versions, in base and in gcc port, making any code 
> containing both C++ and fortran impossible to run. Your application 
> probably can't work on FreeBSD using gcc fortran for this reason.
> 

Huh?  I use Netlib blas/lapack compiled with gfortran on FreeBSD
with no problem.  If you're having problems with gfortran finding
the right libgcc_s.so, then add -rpath /usr/local/lib/gcc5 (or gcc6
or gcc7) to yout Fortran options.

-- 
Steve
___
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: ports index after upgrade 10.4 --> 11.1Stable ?

2017-10-16 Thread Werner Griessl 

On 10/13/17 17:38, Adam Weinberger wrote:

On 11 Oct, 2017, at 7:48, Werner Griessl  wrote:

After an Upgrade from 10.3 Stable --> 11.1 Stable, the /usr/ports/INDEX-11 doesnt build 
after a "portsnap fetch upgrade"
Have always to do "cd /usr/ports; make index" after a portsnap.

What is wrong with my system ?


Look in your /etc/portsnap.conf file. At the bottom you'll want to comment out 
the INDEX-10 line, and uncomment INDEX-11.

There's a 'make fetchindex' target that downloads the right INDEX for your 
system rather than making you run 'make index' yourself.

# Adam




Thanks Adam, that was ist !
Werner


--
Werner Grießl  D-95440 Bayreuth, Germany
Universitaet Bayreuth  Tel.: +49 921 55 2685
IT-Servicezentrum/NetzeNW2 3.2.U1.143
___
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: gnu ltdl and FreeBSD

2017-10-16 Thread blubee blubeeme 
I had an idea that maybe the port was failing because of Clang compiler, so
I looked through the porters handbook and found
USE_GCC

this prompted me to install gcc 6.2 which i think is a little overkill plus
it also installed a few other packages as well. The build went through and
failed at this step trying to install

how can I control which version of gcc to use? I think this project should
build fine with gcc 4.8

install -m 0644 ./iconv.3
/usr/ports/converters/libiconv/work/stage/usr/local/man/man3/iconv.3
install -m 0644 ./iconv_close.3
/usr/ports/converters/libiconv/work/stage/usr/local/man/man3/iconv_close.3
install -m 0644 ./iconv_open.3
/usr/ports/converters/libiconv/work/stage/usr/local/man/man3/iconv_open.3
install -m 0644 ./iconv_open_into.3
/usr/ports/converters/libiconv/work/stage/usr/local/man/man3/iconv_open_into.3
install -m 0644 ./iconvctl.3
/usr/ports/converters/libiconv/work/stage/usr/local/man/man3/iconvctl.3
if [ ! -d
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv ] ;
then /bin/sh ../build-aux/mkinstalldirs
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv ; fi
mkdir /usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv
builddir="`pwd`"; cd . && for f in *.html ; do (cd "$builddir"; echo
install  -m 0644 ./$f
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv/$f ;
install  -m 0644 ./$f
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv/$f)
; done
install -m 0644 ./iconv.1.html
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv/iconv.1.html
install -m 0644 ./iconv.3.html
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv/iconv.3.html
install -m 0644 ./iconv_close.3.html
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv/iconv_close.3.html
install -m 0644 ./iconv_open.3.html
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv/iconv_open.3.html
install -m 0644 ./iconv_open_into.3.html
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv/iconv_open_into.3.html
install -m 0644 ./iconvctl.3.html
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv/iconvctl.3.html
> Compressing man pages (compress-man)
> Running Q/A tests (stage-qa)
Warning: 'lib/libcharset.so.1.0.0' is not stripped consider trying
INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Warning: 'lib/libiconv.so.2.5.1' is not stripped consider trying
INSTALL_TARGET=install-strip or using ${STRIP_CMD}
===>  Installing for libiconv-1.14_11
===>  Checking if libiconv already installed
===>   An older version of libiconv is already installed (libiconv-1.14_10)
  You may wish to ``make deinstall'' and install this port again
  by ``make reinstall'' to upgrade it properly.
  If you really wish to overwrite the old port of libiconv
  without deleting it first, set the variable "FORCE_PKG_REGISTER"
  in your environment or the "make install" command line.
*** Error code 1

Stop.
make[4]: stopped in /usr/ports/converters/libiconv
*** Error code 1


On Mon, Oct 16, 2017 at 5:50 PM, blubee blubeeme 
wrote:

> @Baptiste
>
> adding localbase to the USES macros made it past the previous errors. The
> compilation fails with this error:
>
> gmake[4]: Entering directory '/usr/ports/graphics/utsushi/
> work/utsushi-c590592/lib'
> depbase=`echo connexion.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
> /bin/sh ../libtool  --tag=CXX   --mode=compile c++ -DHAVE_CONFIG_H   -I..
> -pthread -I/usr/local/include  
> -DPKGLIBEXECDIR="\"/usr/local/libexec/utsushi\""
> -DPKGLIBDIR="\"/usr/local/lib/utsushi\"" 
> -DPKGDATADIR="\"/usr/local/share/utsushi\""
> -DLOCALEDIR="\"/usr/local/share/locale\"" 
> -DPKGSYSCONFDIR="\"/usr/local/etc/utsushi\""
> -DPKGCONFFILE="\"utsushi.conf\"" -DCOMBOCONFFILE="\"combo.conf\""
> -isystem /usr/local/include -I/usr/local/include -I/usr/local/include -Wall
> -Werror -O2 -pipe -fstack-protector -isystem /usr/local/include
> -fno-strict-aliasing  -isystem /usr/local/include -MT connexion.lo -MD -MP
> -MF $depbase.Tpo -c -o connexion.lo connexion.cpp &&\
> mv -f $depbase.Tpo $depbase.Plo
> libtool: compile:  c++ -DHAVE_CONFIG_H -I.. -pthread -I/usr/local/include
> -DPKGLIBEXECDIR=\"/usr/local/libexec/utsushi\"
> -DPKGLIBDIR=\"/usr/local/lib/utsushi\" 
> -DPKGDATADIR=\"/usr/local/share/utsushi\"
> -DLOCALEDIR=\"/usr/local/share/locale\" 
> -DPKGSYSCONFDIR=\"/usr/local/etc/utsushi\"
> -DPKGCONFFILE=\"utsushi.conf\" -DCOMBOCONFFILE=\"combo.conf\" -isystem
> /usr/local/include -I/usr/local/include -I/usr/local/include -Wall -Werror
> -O2 -pipe -fstack-protector -isystem /usr/local/include
> -fno-strict-aliasing -isystem /usr/local/include -MT connexion.lo -MD -MP
> -MF .deps/connexion.Tpo -c connexion.cpp  -fPIC -DPIC -o .libs/connexion.o
> In file included from connexion.cpp:44:
> ../utsushi/log.hpp:155:36: error: instantiation of variable
>

Re: gnu ltdl and FreeBSD

2017-10-16 Thread blubee blubeeme 
@Baptiste

adding localbase to the USES macros made it past the previous errors. The
compilation fails with this error:

gmake[4]: Entering directory
'/usr/ports/graphics/utsushi/work/utsushi-c590592/lib'
depbase=`echo connexion.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../libtool  --tag=CXX   --mode=compile c++ -DHAVE_CONFIG_H   -I..
-pthread -I/usr/local/include
 -DPKGLIBEXECDIR="\"/usr/local/libexec/utsushi\""
-DPKGLIBDIR="\"/usr/local/lib/utsushi\""
-DPKGDATADIR="\"/usr/local/share/utsushi\""
-DLOCALEDIR="\"/usr/local/share/locale\""
-DPKGSYSCONFDIR="\"/usr/local/etc/utsushi\""
-DPKGCONFFILE="\"utsushi.conf\"" -DCOMBOCONFFILE="\"combo.conf\"" -isystem
/usr/local/include -I/usr/local/include -I/usr/local/include -Wall -Werror
-O2 -pipe -fstack-protector -isystem /usr/local/include
-fno-strict-aliasing  -isystem /usr/local/include -MT connexion.lo -MD -MP
-MF $depbase.Tpo -c -o connexion.lo connexion.cpp &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  c++ -DHAVE_CONFIG_H -I.. -pthread -I/usr/local/include
-DPKGLIBEXECDIR=\"/usr/local/libexec/utsushi\"
-DPKGLIBDIR=\"/usr/local/lib/utsushi\"
-DPKGDATADIR=\"/usr/local/share/utsushi\"
-DLOCALEDIR=\"/usr/local/share/locale\"
-DPKGSYSCONFDIR=\"/usr/local/etc/utsushi\" -DPKGCONFFILE=\"utsushi.conf\"
-DCOMBOCONFFILE=\"combo.conf\" -isystem /usr/local/include
-I/usr/local/include -I/usr/local/include -Wall -Werror -O2 -pipe
-fstack-protector -isystem /usr/local/include -fno-strict-aliasing -isystem
/usr/local/include -MT connexion.lo -MD -MP -MF .deps/connexion.Tpo -c
connexion.cpp  -fPIC -DPIC -o .libs/connexion.o
In file included from connexion.cpp:44:
../utsushi/log.hpp:155:36: error: instantiation of variable
'utsushi::log::basic_logger::os_'
required here,
  but no definition is available [-Werror,-Wundefined-var-template]
  basic_logger::os_ << *this;
   ^
../utsushi/log.hpp:265:23: note: in instantiation of member function
'utsushi::log::basic_message::~basic_message' requested here
  expand_named_ctors (fatal, FATAL);
  ^
../utsushi/log.hpp:49:47: note: forward declaration of template entity is
here
static std::basic_ostream& os_;
  ^
1 error generated.


looking through the config.log files I see many similar errors such as:
/usr/bin/ld: cannot find -lusb-1.0
cc: error: linker command failed with exit code 1 (use -v to see invocation)
configure:24532: $? = 1

configure:15640: result: no
configure:15644: checking for shl_load in -ldld
configure:15669: cc -o conftest -O2 -pipe  -fstack-protector -isystem
/usr/local/include -fno-strict-aliasing -isystem /usr/local/include
-I/usr/local/include  -fstack-protector -L/usr/local/lib conftest.c -ldld
>&5
/usr/bin/ld: cannot find -ldld

configure:19867: cc -o conftest -O2 -pipe  -fstack-protector -isystem
/usr/local/include -fno-strict-aliasing -isystem /usr/local/include
-I/usr/local/include  -fstack-protector -L/usr/local/lib conftest.c -ldld
>&5
/usr/bin/ld: cannot find -ldld
cc: error: linker command failed with exit code 1 (use -v to see invocation)

are those the reasons for the compilation error up above?


On Mon, Oct 16, 2017 at 5:09 PM, Baptiste Daroussin 
wrote:

> On Mon, Oct 16, 2017 at 08:58:32AM +, blubee blubeeme wrote:
> > I've tried passing CONFIGURE_ARGS or removing it, both gives the same
> error
> > below.
> > LIB_DEPENDS= libltdl.so:devel/libltdl
> > GNU_CONFIGURE=   yes
> > CONFIGURE_ARGS= --enable-ltdl-install
> > USES=autoreconf gmake libtool
> >
> > the config.log file is there and it's pretty long as well I am looking
> > through it but I am not sure what exactly to look for.
> >
> > Here's a pastebin with that config.log file:
> https://pastebin.com/NjkgBTeM
>
> configure:20354: cc -o conftest -O2 -pipe  -fstack-protector
> -fno-strict-aliasing -I/usr/local/include  -fstack-protector conftest.c
> -lltdl
> >&5
> /usr/bin/ld: cannot find -lltdl
>
>
> this is your failure.
>
> Try adding USES=localbase and if it fails adding USES=localbase:ldflags
>
> Bapt
>
___
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: Using blaslapack

2017-10-16 Thread Tijl Coosemans 
On Mon, 16 Oct 2017 09:20:26 +0300 Gleb Popov <6year...@gmail.com> wrote:
> I'm porting an application (DLib, https://reviews.freebsd.org/D12559) that
> uses BLAS and LAPACK, and I have some questions.
> 
> 1. Is there any pure C implementation that does not require Fortran
> compiler?

Probably not, BLAS and LAPACK are Fortran libraries.  Any implementation
in C still provides Fortran wrappers.  And often these implementations
only implement performance critical functions and use the original
Fortran for everything else.

> 2. My application looks for cblas_ddot function in BLAS library, but the
> default library (netlib) doesn't seem to have that. It has ddot, though, so
> I'm not sure if it is a wrong check on app's side, or netlib is indeed
> doesn't suit there. For now I've used openblas, but I'm also not sure if it
> is a right choice.

It's part of CBLAS which is also included in OpenBLAS.

> 3. How to link properly to any of BLAS libraries? All BLAS implementations
> blaslapack.mk features require Fortran. This implies USE_GCC=yes, so these
> are compiled with GCC, not Clang. Now when I try to link Clang-compiled
> DLib to GCC-compiled openblas, I get undefined references:
> 
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__getf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__floatunditf@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__subtf3@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__multf3@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__unordtf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__lttf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__addtf3@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__gttf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__divtf3@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__letf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__netf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__floatditf@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__eqtf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__floatsitf@GCC_4.6.0'
> 
> I've tracked these symbols to /usr/local/lib/gcc6/libgcc_s.so. But there is
> also /usr/lib/libgcc_s.so and it doesn't have such symbols. I suspect this
> is the source of the error, but I wasn't able to fix it. Passing -Wl,-rpath
> as advised by lang/gcc6 pkg-message doesn't help. The only workaround I
> came up with is USE_GCC=yes to compile DLib itself, but that's pretty
> unsatisfactory.

This is a known problem.  If your port depends on another port that
has USES=fortran the easiest is to add USES=fortran to your port as
well.  C code will still be built with Clang then.
___
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: Using blaslapack

2017-10-16 Thread Yuri 

On 10/16/17 02:18, Yuri wrote:


You can try to apply the patch from 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220313 and then have 
USES=fortran:flang instead of just USES=fortran in your port. Please 
let me know if this works. flang is a new, experimental fortran 
implementation that aims to replace gcc fortran.




Sorry, you also need to set USES=fortran:flang in blas/lapack and 
rebuild them too. All involved fortran-using ports need to use flang.



Yuri

___
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: Using blaslapack

2017-10-16 Thread Yuri 

On 10/15/17 23:20, Gleb Popov wrote:

I've tracked these symbols to /usr/local/lib/gcc6/libgcc_s.so. But there is
also /usr/lib/libgcc_s.so and it doesn't have such symbols. I suspect this
is the source of the error, but I wasn't able to fix it. Passing -Wl,-rpath
as advised by lang/gcc6 pkg-message doesn't help. The only workaround I
came up with is USE_GCC=yes to compile DLib itself, but that's pretty
unsatisfactory.



Fortran implementation based on gcc is faulty due to libgcc_s.so being 
present in 2 versions, in base and in gcc port, making any code 
containing both C++ and fortran impossible to run. Your application 
probably can't work on FreeBSD using gcc fortran for this reason.



You can try to apply the patch from 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220313 and then have 
USES=fortran:flang instead of just USES=fortran in your port. Please let 
me know if this works. flang is a new, experimental fortran 
implementation that aims to replace gcc fortran.



Yuri


___
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: gnu ltdl and FreeBSD

2017-10-16 Thread Baptiste Daroussin 
On Mon, Oct 16, 2017 at 08:58:32AM +, blubee blubeeme wrote:
> I've tried passing CONFIGURE_ARGS or removing it, both gives the same error
> below.
> LIB_DEPENDS= libltdl.so:devel/libltdl
> GNU_CONFIGURE=   yes
> CONFIGURE_ARGS= --enable-ltdl-install
> USES=autoreconf gmake libtool
> 
> the config.log file is there and it's pretty long as well I am looking
> through it but I am not sure what exactly to look for.
> 
> Here's a pastebin with that config.log file: https://pastebin.com/NjkgBTeM

configure:20354: cc -o conftest -O2 -pipe  -fstack-protector
-fno-strict-aliasing -I/usr/local/include  -fstack-protector conftest.c -lltdl
>&5
/usr/bin/ld: cannot find -lltdl


this is your failure.

Try adding USES=localbase and if it fails adding USES=localbase:ldflags

Bapt


signature.asc
Description: PGP signature

Re: gnu ltdl and FreeBSD

2017-10-16 Thread blubee blubeeme 
I've tried passing CONFIGURE_ARGS or removing it, both gives the same error
below.
LIB_DEPENDS= libltdl.so:devel/libltdl
GNU_CONFIGURE=   yes
CONFIGURE_ARGS= --enable-ltdl-install
USES=autoreconf gmake libtool

the config.log file is there and it's pretty long as well I am looking
through it but I am not sure what exactly to look for.

Here's a pastebin with that config.log file: https://pastebin.com/NjkgBTeM

both lt_dlinit and lt_dlopen are being used, grep output below.

me@blubee:/usr/ports/graphics/utsushi % grep -rn "lt_dlinit"
work/utsushi-c590592/
work/utsushi-c590592/lib/run-time.cpp:370:  lt_dlinit ();
work/utsushi-c590592/drivers/esci/interpreter.cpp:81:  lt_dlinit ();
work/utsushi-c590592/upstream/aclocal/ltdl.m4:152:  AC_CHECK_LIB([ltdl],
[lt_dlinit], [lt_lib_ltdl=yes])
work/utsushi-c590592/upstream/ltdl/ltdl.h:53:LT_SCOPE intlt_dlinit
(void);
work/utsushi-c590592/upstream/ltdl/ltdl.c:226:lt_dlinit (void)
me@blubee:/usr/ports/graphics/utsushi % grep -rn "lt_dlopen"
work/utsushi-c590592/
work/utsushi-c590592/configure:19663: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}dlopen.la"
work/utsushi-c590592/configure:19684:LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}dlopen.la"
work/utsushi-c590592/configure:19727: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}dlopen.la"
work/utsushi-c590592/configure:19760: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}shl_load.la"
work/utsushi-c590592/configure:19802:LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}shl_load.la"
work/utsushi-c590592/configure:19818: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}dyld.la"
work/utsushi-c590592/configure:19823:  LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}load_add_on.la"
work/utsushi-c590592/configure:19838:  LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}loadlibrary.la"
work/utsushi-c590592/configure:19882: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}dld_link.la"
work/utsushi-c590592/configure.libtool.bak:19663: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}dlopen.la"
work/utsushi-c590592/configure.libtool.bak:19684:
 LT_DLLOADERS="$LT_DLLOADERS ${lt_dlopen_dir+$lt_dlopen_dir/}dlopen.la"
work/utsushi-c590592/configure.libtool.bak:19727: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}dlopen.la"
work/utsushi-c590592/configure.libtool.bak:19760: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}shl_load.la"
work/utsushi-c590592/configure.libtool.bak:19802:
 LT_DLLOADERS="$LT_DLLOADERS ${lt_dlopen_dir+$lt_dlopen_dir/}shl_load.la"
work/utsushi-c590592/configure.libtool.bak:19818: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}dyld.la"
work/utsushi-c590592/configure.libtool.bak:19823:
 LT_DLLOADERS="$LT_DLLOADERS ${lt_dlopen_dir+$lt_dlopen_dir/}load_add_on.la"
work/utsushi-c590592/configure.libtool.bak:19838:
 LT_DLLOADERS="$LT_DLLOADERS ${lt_dlopen_dir+$lt_dlopen_dir/}loadlibrary.la"
work/utsushi-c590592/configure.libtool.bak:19882: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}dld_link.la"
work/utsushi-c590592/lib/scanner.cpp:81:  handle = lt_dlopenadvise
(plugin.c_str (), advice);
work/utsushi-c590592/lib/scanner.cpp:114:  handle = lt_dlopenext
(p.string ().c_str ());
work/utsushi-c590592/drivers/esci/interpreter.cpp:157:  lt_dlhandle handle
= lt_dlopenext (interpreter.c_str ());
work/utsushi-c590592/autom4te.cache/output.0:19663: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}dlopen.la"
work/utsushi-c590592/autom4te.cache/output.0:19684:
 LT_DLLOADERS="$LT_DLLOADERS ${lt_dlopen_dir+$lt_dlopen_dir/}dlopen.la"
work/utsushi-c590592/autom4te.cache/output.0:19727: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}dlopen.la"
work/utsushi-c590592/autom4te.cache/output.0:19760: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}shl_load.la"
work/utsushi-c590592/autom4te.cache/output.0:19802:
 LT_DLLOADERS="$LT_DLLOADERS ${lt_dlopen_dir+$lt_dlopen_dir/}shl_load.la"
work/utsushi-c590592/autom4te.cache/output.0:19818: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}dyld.la"
work/utsushi-c590592/autom4te.cache/output.0:19823:
 LT_DLLOADERS="$LT_DLLOADERS ${lt_dlopen_dir+$lt_dlopen_dir/}load_add_on.la"
work/utsushi-c590592/autom4te.cache/output.0:19838:
 LT_DLLOADERS="$LT_DLLOADERS ${lt_dlopen_dir+$lt_dlopen_dir/}loadlibrary.la"
work/utsushi-c590592/autom4te.cache/output.0:19882: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}dld_link.la"
work/utsushi-c590592/autom4te.cache/traces.2:5562: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}dlopen.la"],
work/utsushi-c590592/autom4te.cache/traces.2:5570:
 LT_DLLOADERS="$LT_DLLOADERS ${lt_dlopen_dir+$lt_dlopen_dir/}dlopen.la"],
work/utsushi-c590592/autom4te.cache/traces.2:5575: LT_DLLOADERS="$LT_DLLOADERS

Re: gnu ltdl and FreeBSD

2017-10-16 Thread Tijl Coosemans 
On Mon, 16 Oct 2017 10:44:42 +0200 Tijl Coosemans  wrote:
> On Mon, 16 Oct 2017 13:37:57 +0800 blubee blubeeme  
> wrote:
>> CONFIGURE_ARGS=  --without-included-ltdl --disable-ltdl-install
>> USES=autoreconf gmake  
> 
> Here you should add "libtool" to USES.

You may also have to add "localbase".
___
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: gnu ltdl and FreeBSD

2017-10-16 Thread Baptiste Daroussin 
On Mon, Oct 16, 2017 at 08:25:57AM +, blubee blubeeme wrote:
> This is what the Makefile looks like, the file still fails:
> 
> LICENSE=  GPLv3+
> BUILD_DEPENDS=  gsed:textproc/gsed
> 
> BINARY_ALIAS=sed=gsed
> 
> LIB_DEPENDS= libltdl.so:devel/libltdl
> GNU_CONFIGURE=   yes
> USES=autoreconf gmake
> 
> same compile error.
> That config.h should be auto generated and setup by autoreconf but its not.

The config.h is not setup by autoreconf neither generated by autoreconf. the run
of the configure script should generated it except if it fails. Have you read
the config.log (very long and verbose script that explains what happened -
including failures - during the run of the configure script)

Also you should add "libtool" to your USES line

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: gnu ltdl and FreeBSD

2017-10-16 Thread Tijl Coosemans 
On Mon, 16 Oct 2017 13:37:57 +0800 blubee blubeeme  wrote:
> I'm trying to port some software that keeps failing when it tries to find a
> config.h.
> 
> I know the config.h file is there but I think the compilation is failing
> because it's trying to build ltdl and freebsd doesn't need that since
> freebsd already has dlopen in libc.
> 
> Which configure flag could I try to get rid of building that lib? The full
> configure --help file is below.
> 
> My current makefile has these settings:
> HAS_CONFIGURE=   yes

This should be GNU_CONFIGURE=yes.

> CONFIGURE_ARGS=  --without-included-ltdl --disable-ltdl-install
> USES=autoreconf gmake

Here you should add "libtool" to USES.

And maybe the code really needs libltdl.  See if there are any calls to
lt_dlinit or lt_dlopen.  You can then add this dependency:

LIB_DEPENDS=libltdl.so:devel/libltdl
___
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: gnu ltdl and FreeBSD

2017-10-16 Thread blubee blubeeme 
This is what the Makefile looks like, the file still fails:

LICENSE=  GPLv3+
BUILD_DEPENDS=  gsed:textproc/gsed

BINARY_ALIAS=sed=gsed

LIB_DEPENDS= libltdl.so:devel/libltdl
GNU_CONFIGURE=   yes
USES=autoreconf gmake

same compile error.
That config.h should be auto generated and setup by autoreconf but its not.

On Mon, Oct 16, 2017 at 4:07 PM, Baptiste Daroussin 
wrote:

> On Mon, Oct 16, 2017 at 05:37:57AM +, blubee blubeeme wrote:
> > I'm trying to port some software that keeps failing when it tries to
> find a
> > config.h.
> >
> > I know the config.h file is there but I think the compilation is failing
> > because it's trying to build ltdl and freebsd doesn't need that since
> > freebsd already has dlopen in libc.
> >
> > Which configure flag could I try to get rid of building that lib? The
> full
> > configure --help file is below.
> >
> > My current makefile has these settings:
> > HAS_CONFIGURE=   yes
> > CONFIGURE_ARGS=  --without-included-ltdl --disable-ltdl-install
> > USES=autoreconf gmake
>
> First this is wrong, if you have USES=autoreconf it means you are using GNU
> configure, so s/HAS_CONFIGURE/GNU_CONFIGURE/g
>
> Do you have libltdl.so:devel/libltdl in your LIB_DEPENDS line
>
> Bapt
>
___
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: gnu ltdl and FreeBSD

2017-10-16 Thread Baptiste Daroussin 
On Mon, Oct 16, 2017 at 05:37:57AM +, blubee blubeeme wrote:
> I'm trying to port some software that keeps failing when it tries to find a
> config.h.
> 
> I know the config.h file is there but I think the compilation is failing
> because it's trying to build ltdl and freebsd doesn't need that since
> freebsd already has dlopen in libc.
> 
> Which configure flag could I try to get rid of building that lib? The full
> configure --help file is below.
> 
> My current makefile has these settings:
> HAS_CONFIGURE=   yes
> CONFIGURE_ARGS=  --without-included-ltdl --disable-ltdl-install
> USES=autoreconf gmake

First this is wrong, if you have USES=autoreconf it means you are using GNU
configure, so s/HAS_CONFIGURE/GNU_CONFIGURE/g

Do you have libltdl.so:devel/libltdl in your LIB_DEPENDS line

Bapt


signature.asc
Description: PGP signature

Re: Using blaslapack

2017-10-16 Thread Mehmet Erol Sanliturk 
On Mon, Oct 16, 2017 at 9:20 AM, Gleb Popov <6year...@gmail.com> wrote:

> Hello.
>
> I'm porting an application (DLib, https://reviews.freebsd.org/D12559) that
> uses BLAS and LAPACK, and I have some questions.
>
> 1. Is there any pure C implementation that does not require Fortran
> compiler?
>


Please see :


http://www.netlib.org/clapack/
http://www.netlib.org/blas/#_cblas



Mehmet Erol Sanliturk







>
> 2. My application looks for cblas_ddot function in BLAS library, but the
> default library (netlib) doesn't seem to have that. It has ddot, though, so
> I'm not sure if it is a wrong check on app's side, or netlib is indeed
> doesn't suit there. For now I've used openblas, but I'm also not sure if it
> is a right choice.
>
> 3. How to link properly to any of BLAS libraries? All BLAS implementations
> blaslapack.mk features require Fortran. This implies USE_GCC=yes, so these
> are compiled with GCC, not Clang. Now when I try to link Clang-compiled
> DLib to GCC-compiled openblas, I get undefined references:
>
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__getf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__floatunditf@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__subtf3@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__multf3@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__unordtf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__lttf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__addtf3@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__gttf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__divtf3@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__letf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__netf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__floatditf@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__eqtf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__floatsitf@GCC_4.6.0'
>
> I've tracked these symbols to /usr/local/lib/gcc6/libgcc_s.so. But there
> is
> also /usr/lib/libgcc_s.so and it doesn't have such symbols. I suspect this
> is the source of the error, but I wasn't able to fix it. Passing -Wl,-rpath
> as advised by lang/gcc6 pkg-message doesn't help. The only workaround I
> came up with is USE_GCC=yes to compile DLib itself, but that's pretty
> unsatisfactory.
>
> Thanks in advance.
> ___
> 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"
>
___
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: ports: pkg-static: "x86_64-unknown-freebsd" versus "x86_64-portbld-freebsd"

2017-10-16 Thread O. Hartmann 
On Sun, 15 Oct 2017 23:38:54 -0700
Mark Millard  wrote:

> O. Hartmann ohartmann at walstatt.org wrote on
> Sun Oct 15 16:37:58 UTC 2017 :
> 
> > . . .
> > file 
> > /usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-unknown-freebsd12.0-avx.bc:No
> > such file or directory pkg-static: Unable to access
> > . . .
> > find ./ -name "*freebsd12.0-avx.bc" -print
> > ./work/stage/usr/local/share/pocl/kernel-x86_64-portbld-freebsd12.0-avx.bc
> > ./work/pocl-0.14/lib/kernel/host/kernel-x86_64-portbld-freebsd12.0-avx.bc
> > . . .
> > so it seems to me as "unknown" gets replaced by "portbld".
> > . . .  
> 
> I do not know if this will help or not. Using a powerpc64
> context as an example:
> 
> In "modern times" devel/powerpc64-gcc generates -unknown- in names
> and lang/gcc* on that environment generates -portbld- in names. This
> helps allows for both devel/powerpc64-gcc and lang/gcc being installed
> in a powerpc64 context: it avoids file name conflicts.
> 
> So, for example:
> (I do not have lang/gcc around but do have lang/gcc7 .)
> 
> # ls -lTd /usr/local/bin/*portb*
> -r-xr-xr-x  4 root  wheel  3617405 Sep 30 23:33:03
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-c++7 -r-xr-xr-x  4 root
> wheel  3617405 Sep 30 23:33:03
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-g++7 -r-xr-xr-x  3 root
> wheel  3610452 Sep 30 23:33:06
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-gcc-7.2.0 -r-xr-xr-x  2
> root  wheel   121242 Sep 30 23:33:06
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-gcc-ar7 -r-xr-xr-x  2 root
> wheel   121146 Sep 30 23:33:07
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-gcc-nm7 -r-xr-xr-x  2 root
> wheel   121166 Sep 30 23:33:07
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-gcc-ranlib7 -r-xr-xr-x  3
> root  wheel  3610452 Sep 30 23:33:06
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-gcc7 -r-xr-xr-x  2 root
> wheel  3620002 Sep 30 23:33:03
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-gfortran7
> 
> # ls -lTd /usr/local/bin/*unknow*
> -r-xr-xr-x  2 root  wheel  3237168 Oct  1 01:17:24
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-c++ -rwxr-xr-x  1 root
> wheel  3235584 Oct  1 01:17:30
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-cpp -r-xr-xr-x  2 root
> wheel  3237168 Oct  1 01:17:24
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-g++ -r-xr-xr-x  2 root
> wheel  3234328 Oct  1 01:17:34
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc -r-xr-xr-x  2 root
> wheel  3234328 Oct  1 01:17:34
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-6.3.0 -r-xr-xr-x  1
> root  wheel   121176 Oct  1 01:17:35
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-ar -r-xr-xr-x  1 root
> wheel   120808 Oct  1 01:17:35
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-nm -r-xr-xr-x  1 root
> wheel   120824 Oct  1 01:17:35
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-ranlib -r-xr-xr-x  1
> root  wheel  2347112 Oct  1 01:17:26
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcov -r-xr-xr-x  1 root
> wheel  2091280 Oct  1 01:17:26
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcov-tool
> 
> Something like this might be involved in your context?
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 

Hello Mark.

Port lang/pocl, 0.14, built flawless in the past, as it is usually compiled
with LLVM/CLANG. Something changed in the past weeks and I got noticed that
poudriere failed installing the port. I do not use gcc of any kind and I have
already proposed for a patch, but your statement/email make me rethink this
approach; the difference might be by intention, but if so, I do not understand
the logic of port's Mk infrastructure, simply because I'm not into it. The
changes to the port's system must have been recently made, lang/pocl built a
couple of weeks ago on 12-CURRENT without any problems. After I got the
poudriere failure notice, I tried on my installations and it failed to install
there, too.

So, the big question for me to answer is: is it a bug or is it a new feature
reflecting the need to sketched above ...

Thanks for answering,

Oliver
___
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: ports: pkg-static: "x86_64-unknown-freebsd" versus "x86_64-portbld-freebsd"

2017-10-16 Thread Mark Millard 
O. Hartmann ohartmann at walstatt.org wrote on
Sun Oct 15 16:37:58 UTC 2017 :

> . . .
> file 
> /usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-unknown-freebsd12.0-avx.bc:No
> such file or directory pkg-static: Unable to access
> . . .
> find ./ -name "*freebsd12.0-avx.bc" -print
> ./work/stage/usr/local/share/pocl/kernel-x86_64-portbld-freebsd12.0-avx.bc
> ./work/pocl-0.14/lib/kernel/host/kernel-x86_64-portbld-freebsd12.0-avx.bc
> . . .
> so it seems to me as "unknown" gets replaced by "portbld".
> . . .

I do not know if this will help or not. Using a powerpc64
context as an example:

In "modern times" devel/powerpc64-gcc generates -unknown- in names
and lang/gcc* on that environment generates -portbld- in names. This
helps allows for both devel/powerpc64-gcc and lang/gcc being installed
in a powerpc64 context: it avoids file name conflicts.

So, for example:
(I do not have lang/gcc around but do have lang/gcc7 .)

# ls -lTd /usr/local/bin/*portb*
-r-xr-xr-x  4 root  wheel  3617405 Sep 30 23:33:03 2017 
/usr/local/bin/powerpc64-portbld-freebsd12.0-c++7
-r-xr-xr-x  4 root  wheel  3617405 Sep 30 23:33:03 2017 
/usr/local/bin/powerpc64-portbld-freebsd12.0-g++7
-r-xr-xr-x  3 root  wheel  3610452 Sep 30 23:33:06 2017 
/usr/local/bin/powerpc64-portbld-freebsd12.0-gcc-7.2.0
-r-xr-xr-x  2 root  wheel   121242 Sep 30 23:33:06 2017 
/usr/local/bin/powerpc64-portbld-freebsd12.0-gcc-ar7
-r-xr-xr-x  2 root  wheel   121146 Sep 30 23:33:07 2017 
/usr/local/bin/powerpc64-portbld-freebsd12.0-gcc-nm7
-r-xr-xr-x  2 root  wheel   121166 Sep 30 23:33:07 2017 
/usr/local/bin/powerpc64-portbld-freebsd12.0-gcc-ranlib7
-r-xr-xr-x  3 root  wheel  3610452 Sep 30 23:33:06 2017 
/usr/local/bin/powerpc64-portbld-freebsd12.0-gcc7
-r-xr-xr-x  2 root  wheel  3620002 Sep 30 23:33:03 2017 
/usr/local/bin/powerpc64-portbld-freebsd12.0-gfortran7

# ls -lTd /usr/local/bin/*unknow*
-r-xr-xr-x  2 root  wheel  3237168 Oct  1 01:17:24 2017 
/usr/local/bin/powerpc64-unknown-freebsd12.0-c++
-rwxr-xr-x  1 root  wheel  3235584 Oct  1 01:17:30 2017 
/usr/local/bin/powerpc64-unknown-freebsd12.0-cpp
-r-xr-xr-x  2 root  wheel  3237168 Oct  1 01:17:24 2017 
/usr/local/bin/powerpc64-unknown-freebsd12.0-g++
-r-xr-xr-x  2 root  wheel  3234328 Oct  1 01:17:34 2017 
/usr/local/bin/powerpc64-unknown-freebsd12.0-gcc
-r-xr-xr-x  2 root  wheel  3234328 Oct  1 01:17:34 2017 
/usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-6.3.0
-r-xr-xr-x  1 root  wheel   121176 Oct  1 01:17:35 2017 
/usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-ar
-r-xr-xr-x  1 root  wheel   120808 Oct  1 01:17:35 2017 
/usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-nm
-r-xr-xr-x  1 root  wheel   120824 Oct  1 01:17:35 2017 
/usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-ranlib
-r-xr-xr-x  1 root  wheel  2347112 Oct  1 01:17:26 2017 
/usr/local/bin/powerpc64-unknown-freebsd12.0-gcov
-r-xr-xr-x  1 root  wheel  2091280 Oct  1 01:17:26 2017 
/usr/local/bin/powerpc64-unknown-freebsd12.0-gcov-tool

Something like this might be involved in your context?

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

Fwd: [exp - 103i386-default-build-as-user][mail/sa-utils] Failed for sa-utils-0.04 in run-depends

2017-10-16 Thread Matthew Seaman 

Hmmm  This nastygram from pkg-fallout arrived overnight.  However,
as far as I can tell, this is complaining about mail/spamassassin
packages being broken, rather than any problem with mail/sa-utils itself.

However, having checked the Build URL, poudriere seems to think
spamassassin built perfectly well.  Something isn't right here...

Cheers,

Matthew

 Forwarded Message 
Subject: [exp - 103i386-default-build-as-user][mail/sa-utils] Failed for
sa-utils-0.04 in run-depends
Date: Mon, 16 Oct 2017 05:14:09 GMT
From: pkg-fall...@freebsd.org
To: matt...@freebsd.org
CC: pkg-fall...@freebsd.org

You are receiving this mail as a port that you maintain
is failing to build on the FreeBSD package build server.
Please investigate the failure and submit a PR to fix
build.

Maintainer: matt...@freebsd.org
Last committer: matt...@freebsd.org
Ident:  $FreeBSD: head/mail/sa-utils/Makefile 438042 2017-04-08
13:02:36Z matthew $
Log URL:
http://package19.nyi.freebsd.org/data/103i386-default-build-as-user/452169/logs/sa-utils-0.04.log
Build URL:
http://package19.nyi.freebsd.org/build.html?mastername=103i386-default-build-as-user=452169
Log:

>> Building mail/sa-utils
build started at Mon Oct 16 05:14:04 UTC 2017
port directory: /usr/ports/mail/sa-utils
building for: FreeBSD 103i386-default-build-as-user-job-27
10.3-RELEASE-p21 FreeBSD 10.3-RELEASE-p21 i386
maintained by: matt...@freebsd.org
Makefile ident:  $FreeBSD: head/mail/sa-utils/Makefile 438042
2017-04-08 13:02:36Z matthew $
Poudriere version: 3.1.21
Host OSVERSION: 1200042
Jail OSVERSION: 1003000
Job Id: 27

---Begin Environment---
SHELL=/bin/csh
UNAME_p=i386
UNAME_m=i386
OSVERSION=1003000
UNAME_v=FreeBSD 10.3-RELEASE-p21
UNAME_r=10.3-RELEASE-p21
BLOCKSIZE=K
MAIL=/var/mail/root
STATUS=1
SAVED_TERM=
MASTERMNT=/poudriere/data/.m/103i386-default-build-as-user/ref
UID=0
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
POUDRIERE_BUILD_TYPE=bulk
PKGNAME=sa-utils-0.04
OLDPWD=/
PWD=/poudriere/data/.m/103i386-default-build-as-user/ref/.p/pool
MASTERNAME=103i386-default-build-as-user
SCRIPTPREFIX=/usr/local/share/poudriere
USER=root
HOME=/root
POUDRIERE_VERSION=3.1.21
SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
GID=0
LIBEXECPREFIX=/usr/local/libexec/poudriere
LOCALBASE=/usr/local
POUDRIEREPATH=/usr/local/bin/poudriere
---End Environment---

---Begin Poudriere Port Flags/Env---
PORT_FLAGS=
PKGENV=
---End Poudriere Port Flags/Env---

---Begin OPTIONS List---
===> The following configuration options are available for sa-utils-0.04:
 SACOMPILE=off: Enable sa-compile support
===> Use 'make config' to modify these settings
---End OPTIONS List---

--CONFIGURE_ARGS--

--End CONFIGURE_ARGS--

--CONFIGURE_ENV--
XDG_DATA_HOME=/wrkdirs/usr/ports/mail/sa-utils/work
XDG_CONFIG_HOME=/wrkdirs/usr/ports/mail/sa-utils/work
HOME=/wrkdirs/usr/ports/mail/sa-utils/work TMPDIR="/tmp"
PATH=/wrkdirs/usr/ports/mail/sa-utils/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
SHELL=/bin/sh CONFIG_SHELL=/bin/sh
--End CONFIGURE_ENV--

--MAKE_ENV--
XDG_DATA_HOME=/wrkdirs/usr/ports/mail/sa-utils/work
XDG_CONFIG_HOME=/wrkdirs/usr/ports/mail/sa-utils/work
HOME=/wrkdirs/usr/ports/mail/sa-utils/work TMPDIR="/tmp"
PATH=/wrkdirs/usr/ports/mail/sa-utils/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
NO_PIE=yes WITHOUT_DEBUG_FILES=yes WITHOUT_KERNEL_SYMBOLS=yes
SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local  LOCALBASE=/usr/local
LIBDIR="/usr/lib"  CC="cc" CFLAGS="-O2 -pipe  -fstack-protector
-fno-strict-aliasing"  CPP="cpp" CPPFLAGS=""  LDFLAGS="
-fstack-protector" LIBS=""  CXX="c++" CXXFLAGS="-O2 -pipe
-fstack-protector -fno-strict-aliasing "  MANPREFIX="/usr/local"
BSD_INSTALL_PROGRAM="install  -s -m 555"  BSD_INSTALL_LIB="install  -s
-m 0644"  BSD_INSTALL_SCRIPT="install  -m 555"
BSD_INSTALL_DATA="install  -m 0644"  BSD_INSTALL_MAN="install  -m 444"
--End MAKE_ENV--

--PLIST_SUB--
OSREL=10.3
PREFIX=%D
LOCALBASE=/usr/local
RESETPREFIX=/usr/local
PORTDOCS=""
PORTEXAMPLES=""
LIB32DIR=lib
DOCSDIR="share/doc/sa-utils"
EXAMPLESDIR="share/examples/sa-utils"
DATADIR="share/sa-utils"
WWWDIR="www/sa-utils"
ETCDIR="etc/sa-utils"
--End PLIST_SUB--

--SUB_LIST--
SACOMPILE=NO
PREFIX=/usr/local
LOCALBASE=/usr/local
DATADIR=/usr/local/share/sa-utils
DOCSDIR=/usr/local/share/doc/sa-utils
EXAMPLESDIR=/usr/local/share/examples/sa-utils
WWWDIR=/usr/local/www/sa-utils
ETCDIR=/usr/local/etc/sa-utils
--End SUB_LIST--

---Begin make.conf---
USE_PACKAGE_DEPENDS=yes
BATCH=yes
WRKDIRPREFIX=/wrkdirs
PORTSDIR=/usr/ports
PACKAGES=/packages
DISTDIR=/distfiles
FORCE_PACKAGE=yes
PACKAGE_BUILDING=yes
MACHINE=i386
MACHINE_ARCH=i386
ARCH=${MACHINE_ARCH}
 /usr/local/etc/poudriere.d/make.conf 
# Build ALLOW_MAKE_JOBS_PACKAGES with 2 jobs
MAKE_JOBS_NUMBER=2
 /usr/ports/Mk/Scripts/ports_env.sh 
ARCH=i386
CONFIGURE_MAX_CMD_LEN=262144
OPSYS=FreeBSD

Using blaslapack

2017-10-16 Thread Gleb Popov 
Hello.

I'm porting an application (DLib, https://reviews.freebsd.org/D12559) that
uses BLAS and LAPACK, and I have some questions.

1. Is there any pure C implementation that does not require Fortran
compiler?

2. My application looks for cblas_ddot function in BLAS library, but the
default library (netlib) doesn't seem to have that. It has ddot, though, so
I'm not sure if it is a wrong check on app's side, or netlib is indeed
doesn't suit there. For now I've used openblas, but I'm also not sure if it
is a right choice.

3. How to link properly to any of BLAS libraries? All BLAS implementations
blaslapack.mk features require Fortran. This implies USE_GCC=yes, so these
are compiled with GCC, not Clang. Now when I try to link Clang-compiled
DLib to GCC-compiled openblas, I get undefined references:

//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__getf2@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__floatunditf@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__subtf3@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__multf3@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__unordtf2@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__lttf2@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__addtf3@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__gttf2@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__divtf3@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__letf2@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__netf2@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__floatditf@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__eqtf2@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__floatsitf@GCC_4.6.0'

I've tracked these symbols to /usr/local/lib/gcc6/libgcc_s.so. But there is
also /usr/lib/libgcc_s.so and it doesn't have such symbols. I suspect this
is the source of the error, but I wasn't able to fix it. Passing -Wl,-rpath
as advised by lang/gcc6 pkg-message doesn't help. The only workaround I
came up with is USE_GCC=yes to compile DLib itself, but that's pretty
unsatisfactory.

Thanks in advance.
___
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"