jsoncpp update breaks cmake

2020-06-30 Thread Kevin Oberman
The update to jsoncpp pumped the version of the .so which requires a
rebuild of cmake. This prevents building a LOT of ports.

Could someone bump the PORT_REVISION for cmake? I have not checked whether
other ports may need a bump, as well.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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 a different linker in a CMake project

2019-09-26 Thread Jan Beich
Willem Jan Withagen  writes:

> Hi,
>
> For building ceph14 in I need to use ld from the ports binutils.
> Mainly because of versioning that I can not get to work with the llvm
> linker, and is a know difference between GNU ld en LLVM ld.
>
> Just building in the project I was able to do that with:
>   -D  CMAKE_CXX_FLAGS_DEBUG=" -fuse-ld=/usr/local/bin/ld
>-Wno-unused-command-line-argument"

Try defining LLD_UNSAFE=yes in port's Makefile. It'd be translated to
LDFLAGS+=-fuse-ld=bfd and then by USES=cmake into

-DCMAKE_EXE_LINKER_FLAGS:STRING="${LDFLAGS}" \
-DCMAKE_MODULE_LINKER_FLAGS:STRING="${LDFLAGS}" \
-DCMAKE_SHARED_LINKER_FLAGS:STRING="${LDFLAGS}" \

  $ make -V CMAKE_ARGS:M\*bfd\* LLD_UNSAFE=
  -DCMAKE_EXE_LINKER_FLAGS:STRING="  -fstack-protector-strong -fuse-ld=bfd " 
-DCMAKE_MODULE_LINKER_FLAGS:STRING="  -fstack-protector-strong -fuse-ld=bfd " 
-DCMAKE_SHARED_LINKER_FLAGS:STRING="  -fstack-protector-strong -fuse-ld=bfd "

However, if you need /usr/local/bin/ld.bfd rather than /usr/bin/ld.bfd
on FreeBSD 11.* define USE_BINUTILS and pass LDFLAGS+=-B${LOCALBASE}/bin .
___
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 a different linker in a CMake project

2019-09-26 Thread Steve Kargl
On Thu, Sep 26, 2019 at 06:18:17PM +0200, Willem Jan Withagen wrote:
> 
> For building ceph14 in I need to use ld from the ports binutils.
> Mainly because of versioning that I can not get to work with the llvm 
> linker, and is a know difference between GNU ld en LLVM ld.
> 
> Just building in the project I was able to do that with:
>-D  CMAKE_CXX_FLAGS_DEBUG=" -fuse-ld=/usr/local/bin/ld 
> -Wno-unused-command-line-argument"
> 
> So I'm trying to pass that also in the ports Makefile as a CMAKE_ARGS.
> But nothing thusfar I've tried does actually work. and gets the option
> on the commandline.
> 
> So is there a way to get this to work.
> It is sort of tricky since CMAKE output uses cc of c++ to do linking.
> 
> A brute force hack would be to
>   rm /usr/bin/ld
>   ln -s /usr/local/bin/ld /usr/bin/ld
> But I sure that that would not make it in the porst tree.
> 

% cat Makefile
PATH = /usr/bin:/bin
.unexport-env
.export PATH

all:
 @echo ${PATH}
 which ld

% which ld
/usr/local/bin/ld
% make
/usr/bin:/bin
which ld
/usr/bin/ld

HTH

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


Using a different linker in a CMake project

2019-09-26 Thread Willem Jan Withagen

Hi,

For building ceph14 in I need to use ld from the ports binutils.
Mainly because of versioning that I can not get to work with the llvm 
linker, and is a know difference between GNU ld en LLVM ld.


Just building in the project I was able to do that with:
  -D  CMAKE_CXX_FLAGS_DEBUG=" -fuse-ld=/usr/local/bin/ld 
-Wno-unused-command-line-argument"


So I'm trying to pass that also in the ports Makefile as a CMAKE_ARGS.
But nothing thusfar I've tried does actually work. and gets the option
on the commandline.

So is there a way to get this to work.
It is sort of tricky since CMAKE output uses cc of c++ to do linking.

A brute force hack would be to
rm /usr/bin/ld
ln -s /usr/local/bin/ld /usr/bin/ld
But I sure that that would not make it in the porst tree.

So suggestions welcomed.
--WjW
___
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: ifdef __linux__ / gtk issue; how to list defined symbols for cmake?

2019-06-28 Thread Gary Aitken

Thanks a boatload for the detailed explanation.

Gary

___
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: ifdef __linux__ / gtk issue; how to list defined symbols for cmake?

2019-06-26 Thread Jan Beich
Gary Aitken  writes:

> 1.  Is there an easy way to get a list of all the __*__ symbols?

# Works for GCC, Clang and some arcane compilers
$ cc -dM -E - Where / how are these set up?

Predefined macros are set by the compiler. Some are architecture-specific,
some are OS-specific, some depend on flags, etc.

https://gcc.gnu.org/onlinedocs/cpp/Predefined-Macros.html

For one, __FreeBSD__ is defined in
/usr/src/contrib/llvm/tools/clang/lib/Basic/Targets/OSTargets.h
/usr/src/contrib/gcc/config/freebsd-spec.h

> Is there a way to list them at the start of compilation of each file
> to check the appropriate ones are all defined in different subdirs
> of the build tree?

Unlikely without hacking the build glue to add a separate step for -dM -E.

> If __linux__ is defined, is __unix__ also defined?  If any of the
> __*BSD__ syms are defined, is __unix__ also defined?

__unix__ is defined on (m)any Unix-like system except macOS despite macOS
being on of the few certified UNIX. Go figure. ;)

https://sourceforge.net/p/predef/wiki/OperatingSystems/

> 3.  What's the relationship between the _WIN32, __APPLE__, __unix__ type
> syms in code and the WIN32, APPLE, UNIX, XCODE syms that I see in
> some of the CMakeLists.txt files?

CMake predefines some variables and even more are defined by cmake-modules(7).
However, UNIX is defined on macOS unlike __unix__. What a rotten apple. ;)

https://github.com/Kitware/CMake/blob/v3.14.5/Source/cmStateSnapshot.cxx#L298-L355
https://github.com/Kitware/CMake/blob/v3.14.5/Source/cmGlobalXCodeGenerator.cxx#L297-L298

>  Are any/all of these case sensitive?

Yep if the underlying programming language is case-sensitive.

> How is CMAKE_SYSTEM_NAME, which may be "Linux" (on linux), related to
>     the above syms?

See /usr/local/share/cmake/Modules/CMakeDetermineSystem.cmake

>
> 4.  Suggestions on how to approach this?  I'm inclined to change the
>   "#if defined(__linux__)" to "#if defined(__WXGTK__)" where appropriate
> instead of adding
>   "|| defined(__FreeBSD__) || defined(__NetBSD__)..." etc.

Probably OK but I don't have experience porting WX-based apps. Try to
insert #error first to make sure __WXGTK__ is defined in all the places
you're trying to use it.

> Is there a "BSD" sym that encompasses the various bsd variants?

AFAIK, "BSD" defined in  is a vestige from when BSD was an
actual Unix distribution developed by CSRG at UC Berkeley. As macOS and
GNU/kFreeBSD also define "BSD" it's not very useful.

https://svnweb.freebsd.org/csrg?view=revision=24654
http://fxr.watson.org/fxr/source/bsd/sys/param.h?v=xnu-2050.18.24#L72
___
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"


ifdef __linux__ / gtk issue; how to list defined symbols for cmake?

2019-06-24 Thread Gary Aitken

I'm working on porting the prusa slicer.  It contains a boatload of
things like
  #if defined _WIN32
...
  #elif defined(__linux__)
...
  #elif defined __APPLE__
...

occasionally there is a

  #if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__) || 
defined(__bsdi__) || defined(__DragonFly__)

or a
  #ifdef __unix__

or a
  #ifdef __WXGTK__(for wxwidgets toolkit mapped to gtk)

It appears that many of the issues for __linux__ are actually gtk issues
which I *think* should be common to linux and bsd under gtk on X.

Questions:

1.  Is there an easy way to get a list of all the __*__ symbols?
Where / how are these set up?
Is there a way to list them at the start of compilation of each file
to check the appropriate ones are all defined in different subdirs
of the build tree?

2.  I'm guessing/hoping the sym definitions are a general configuration
process that mostly happens the same way across all ports.
If __linux__ is defined, is __unix__ also defined?  If any of the
__*BSD__ syms are defined, is __unix__ also defined?

3.  What's the relationship between the _WIN32, __APPLE__, __unix__ type
syms in code and the WIN32, APPLE, UNIX, XCODE syms that I see in
some of the CMakeLists.txt files?  Are any/all of these case sensitive?
How is CMAKE_SYSTEM_NAME, which may be "Linux" (on linux), related to
the above syms?

4.  Suggestions on how to approach this?  I'm inclined to change the
  "#if defined(__linux__)" to "#if defined(__WXGTK__)" where appropriate
instead of adding
  "|| defined(__FreeBSD__) || defined(__NetBSD__)..." etc.
Is there a "BSD" sym that encompasses the various bsd variants?

thoughts / suggestions / things to be careful of?

Thanks,

Gary
___
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: .build directory for cmake

2019-06-04 Thread Tatsuki Makino
Gary Aitken wrote on 2019/06/04 05:48:
> On 6/3/19 2:07 PM, Tatsuki Makino wrote:
> 
>> What if that changes to USES=cmake:insource ?
> 
> If I do that I see no different behavior from USES=cmake, at least in terms
> of trying to reproduce the original problem (which was resolved by removing
> the work/.configure_done* file).

mmm, I think that is a difficult case for me :)
If you reply the result of the following command, you will be helped
by... someone.

make -C /usr/ports/cad/prusa-slicer -n do-configure
make -C /usr/ports/cad/prusa-slicer -V CONFIGURE_WRKSRC -V BUILD_WRKSRC

Sorry for not being useful :)
___
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: .build directory for cmake

2019-06-03 Thread Gary Aitken

On 6/3/19 2:07 PM, Tatsuki Makino wrote:


What if that changes to USES=cmake:insource ?


If I do that I see no different behavior from USES=cmake, at least in terms
of trying to reproduce the original problem (which was resolved by removing
the work/.configure_done* file).
___
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: .build directory for cmake (was: freebsd-ports Digest, Vol 836, Issue 1)

2019-06-03 Thread Tatsuki Makino
Hello.

What if that changes to USES=cmake:insource ?

Regards.
___
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: .build directory for cmake (was: freebsd-ports Digest, Vol 836, Issue 1)

2019-06-03 Thread Gary Aitken

On 6/3/19 8:18 AM, Adriaan de Groot wrote:

On Monday, 3 June 2019 14:00:01 CEST freebsd-ports-requ...@freebsd.org wrote:

From: Gary Aitken 

I'm trying to port some linux code which uses cmake, and clearly don't
know what I'm doing.

I have
USES=  cmake
set, but a
make build
terminates with:
cd: /usr/ports/cad/prusa-slicer/work/.build: No such file or directory

What am I missing?  I presume the .build directory should be automatically
created by the build process.


Are you sure that the configure step is completing succesfully? You'd have to
take a look in WRKDIR (e.g. try WRKDIR=/tmp/bare make configure ) to see what
it's created exactly and where -- if anywhere -- the build-dir has ended up.

I know I've run into this same problem with cmake-based ports, but I don't
remember what I did to resolve it. Feel free to pop into #kde-freebsd on
Freenode IRC to bounce ideas off the FreeBSD devel/cmake maintainers.


Thank you, that was a big help.
There was a .configure_done.prusa-slicer._usr_local but no .build
subdirectory.  If I remove the .configure_done and do a make configure
it correctly creates the .build subdir and populates it, but due to an
error it doesn't complete and so leaves no .configure_done.

So... I can continue work from here, thanks.
What's not clear is how the .configure_done got written in the first place;
I can't reproduce it.

Thanks,

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


.build directory for cmake

2019-06-02 Thread Gary Aitken

I'm trying to port some linux code which uses cmake, and clearly don't
know what I'm doing.

I have
  USES=  cmake
set, but a
  make build
terminates with:
  cd: /usr/ports/cad/prusa-slicer/work/.build: No such file or directory

What am I missing?  I presume the .build directory should be automatically
created by the build process.

Thanks,

Gary
___
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: CMake and python in ceph

2018-12-09 Thread Willem Jan Withagen

Hi,

Just tried building Ceph with the new Cmake 3.13.1, but that does not 
work because

in contrast to past builds it now requires a fixed boost_python version:

# Note that Boost Python components require a Python version suffix
# (Boost 1.67 and later), e.g. ``python36`` or ``python27`` for the
# versions built against Python 3.6 and 2.7, respectively.  This also
# applies to additional components using Python including
# ``mpi_python`` and ``numpy``.  Earlier Boost releases may use
# distribution-specific suffixes such as ``2``, ``3`` or ``2.7``.
# These may also be used as suffixes, but note that they are not
# portable.

So how does that work with all the attempts in ports to build python
version agnostic?

The catch is that I cannot get Ceph to build unless I select a ceph version
for the build. But I'm expecting that I'll fail once I get to poudriere.
(Have not tried that)

So what is the smart way out of this?

--WjW

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


powerpc64 (head -r326075): www/qt5-webkit gets: CMake Error at CMakeLists.txt:85 (message): Unknown CPU 'powerpc64'

2017-12-26 Thread Mark Millard
[I experiment with system clang as the system
compiler for powerpc64 (and 32-bit powerpc).]

On powerpc64,

# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 457194
Last Changed Rev: 457194

gets:

===>  Configuring for qt5-webkit-5.212.0.a2_5
===>  Performing out-of-source build
/bin/mkdir -p /wrkdirs/usr/ports/www/qt5-webkit/work/.build
-- The C compiler identification is Clang 5.0.1
-- The CXX compiler identification is Clang 5.0.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:85 (message):
  Unknown CPU 'powerpc64'


www/qt5-webkit was referenced indirectly from
attempting to build x11/lumina .


===
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: VLC/cmake failing to build

2017-09-23 Thread Kurt Buff
On Sat, Sep 23, 2017 at 12:58 PM, Michael Butler
<i...@protected-networks.net> wrote:
> On 09/23/17 15:46, Kurt Buff wrote:
>>
>> All,
>>
>> Upgraded from 10.3 to 11.0-RELEASE-p12
>>
>> Deleted all installed ports, and am trying to reinstall them with
>> portmaster, building from source, with the following command line:
>>   portmaster -d --no-confirm --no-term-title --delete-packages `cat
>> /root/ports.txt`
>>
>> ports.txt has the following in it:
>>   multimedia/vlc-qt4
>>   net/wireshark
>>   security/sudo
>>   ports-mgmt/bsdadminscripts2
>>   sysutils/coreutils
>>   www/firefox
>>   www/lynx
>>   www/opera
>>   x11-wm/xfce4
>>   x11/xorg
>>
>>
>> VLC is failing to build, with the following error:
>>   ===>>> The dependency for devel/cmake
>>  seems to be handled by cmake-modules-3.8.2
>>
>>   ===>>> The devel/cmake-modules port has been deleted: Deleted,
>> merged into devel/cmake
>>   ===>>> Aborting update
>
>
>  [ .. ]
>
>> How do I fix this?
>
>
> As the error message suggests, cmake-modules no longer exists.
>
> Use "pkg delete -f cmake-modules" and retry,
>
> imb

Well, that's unexpected.

I did a 'pkg delete -a' before the upgrade, and checked to make sure
all of them were indeed gone with 'pkg info'.

Don't know how cmake-modules snuck in...

Thanks,

Kurt
___
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: VLC/cmake failing to build

2017-09-23 Thread George Mitchell
On 09/23/17 15:46, Kurt Buff wrote:
> All,
> 
> Upgraded from 10.3 to 11.0-RELEASE-p12
> 
> Deleted all installed ports, and am trying to reinstall them with
> portmaster, building from source, with the following command line:
>  portmaster -d --no-confirm --no-term-title --delete-packages `cat
> /root/ports.txt`
> 
> ports.txt has the following in it:
>  multimedia/vlc-qt4
>  net/wireshark
>  security/sudo
>  ports-mgmt/bsdadminscripts2
>  sysutils/coreutils
>  www/firefox
>  www/lynx
>  www/opera
>  x11-wm/xfce4
>  x11/xorg
> 
> 
> VLC is failing to build, with the following error:
>  ===>>> The dependency for devel/cmake
> seems to be handled by cmake-modules-3.8.2
> 
>  ===>>> The devel/cmake-modules port has been deleted: Deleted,
> merged into devel/cmake
>  ===>>> Aborting update
>  export: =$ devel_qt5_core multimedia_libva multimedia_libvdpau
> x11_toolkits_qt5_gui x11_toolkits_qt5_widgets x11_qt5_x11extras : bad
> variable name
>  export: =$ devel_qt5_core multimedia_libva multimedia_libvdpau
> x11_toolkits_qt5_gui x11_toolkits_qt5_widgets x11_qt5_x11extras : bad
> variable name
>  export: =$ devel_qt5_core multimedia_libva multimedia_libvdpau
> x11_toolkits_qt5_gui x11_toolkits_qt5_widgets x11_qt5_x11extras : bad
> variable name
> 
> 
> How do I fix this?
> 
> Kurt
> [...]
/usr/ports/UPDATING:

20170914:
  AFFECTS: users of CMake & CMake Modules
  AUTHOR: adr...@freebsd.org

  The devel/cmake-modules port has been merged into devel/cmake.

  The benefit of being able to update the modules without the binary
  is outweighed by the issues caused by having the binary out-of-sync
  with the modules.

  Users should delete the devel/cmake-modules package and then
  upgrade or reinstall devel/cmake.

  All ports have been updated to depend only on CMake.

I.e., "pkg delete cmake-modules; portmaster  devel/cmake"
-- George



signature.asc
Description: OpenPGP digital signature


Re: VLC/cmake failing to build

2017-09-23 Thread Walter Schwarzenfeld

I guess you have to run

pkg delete cmake-modules

___
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: VLC/cmake failing to build

2017-09-23 Thread Michael Butler

On 09/23/17 15:46, Kurt Buff wrote:

All,

Upgraded from 10.3 to 11.0-RELEASE-p12

Deleted all installed ports, and am trying to reinstall them with
portmaster, building from source, with the following command line:
  portmaster -d --no-confirm --no-term-title --delete-packages `cat
/root/ports.txt`

ports.txt has the following in it:
  multimedia/vlc-qt4
  net/wireshark
  security/sudo
  ports-mgmt/bsdadminscripts2
  sysutils/coreutils
  www/firefox
  www/lynx
  www/opera
  x11-wm/xfce4
  x11/xorg


VLC is failing to build, with the following error:
  ===>>> The dependency for devel/cmake
 seems to be handled by cmake-modules-3.8.2

  ===>>> The devel/cmake-modules port has been deleted: Deleted,
merged into devel/cmake
  ===>>> Aborting update


 [ .. ]


How do I fix this?


As the error message suggests, cmake-modules no longer exists.

Use "pkg delete -f cmake-modules" and retry,

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


VLC/cmake failing to build

2017-09-23 Thread Kurt Buff
All,

Upgraded from 10.3 to 11.0-RELEASE-p12

Deleted all installed ports, and am trying to reinstall them with
portmaster, building from source, with the following command line:
 portmaster -d --no-confirm --no-term-title --delete-packages `cat
/root/ports.txt`

ports.txt has the following in it:
 multimedia/vlc-qt4
 net/wireshark
 security/sudo
 ports-mgmt/bsdadminscripts2
 sysutils/coreutils
 www/firefox
 www/lynx
 www/opera
 x11-wm/xfce4
 x11/xorg


VLC is failing to build, with the following error:
 ===>>> The dependency for devel/cmake
seems to be handled by cmake-modules-3.8.2

 ===>>> The devel/cmake-modules port has been deleted: Deleted,
merged into devel/cmake
 ===>>> Aborting update
 export: =$ devel_qt5_core multimedia_libva multimedia_libvdpau
x11_toolkits_qt5_gui x11_toolkits_qt5_widgets x11_qt5_x11extras : bad
variable name
 export: =$ devel_qt5_core multimedia_libva multimedia_libvdpau
x11_toolkits_qt5_gui x11_toolkits_qt5_widgets x11_qt5_x11extras : bad
variable name
 export: =$ devel_qt5_core multimedia_libva multimedia_libvdpau
x11_toolkits_qt5_gui x11_toolkits_qt5_widgets x11_qt5_x11extras : bad
variable name


How do I fix this?

Kurt
___
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: cmake release builds don't disable assertions (NDEBUG)

2017-02-06 Thread Michael Gmelin
On Mon, 06 Feb 2017 22:27:01 +0100
Raphael Kubo da Costa <rak...@freebsd.org> wrote:

> Michael Gmelin <free...@grem.de> writes:
> 
> > While debugging an unexpected assertion problem, I noticed that
> > ports using cmake don't set -NDEBUG, even when building in Release
> > mode.
> >
> > Is this intentional?  
> 
> Is it the software you're porting that checks for DEBUG or some
> library it uses?
> 
> CMake code should check for CMAKE_BUILD_TYPE and adjust the compiler
> flags accordingly (if at all); so if the software itself is checking
> for DEBUG but not passing (or omitting it) I'd say the bug is there,
> not in Mk/Uses/cmake.mk.

Well, cmake.mk overwrites the meaning of CMAKE_CXX_FLAGS_RELEASE with
the content of CXXFLAGS, are you sure that doing this is the right
thing to do?

I sampled a couple of smaller projects that use cmake in the ports tree
and it seems like many projects don't do anything special to prevent
assertions or debug code when built using CMAKE_BUILD_TYPE=Release,
which makes me think that the authors depend on the default behaviour
of cmake, which includes "-NDEBUG" in Release mode (AFAIK default flags
for build types are also compiler and platform dependent, so it kind of
makes sense to rely on the defaults, doesn't it?).

Thanks,
-m

-- 
Michael Gmelin
___
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: cmake release builds don't disable assertions (NDEBUG)

2017-02-06 Thread Raphael Kubo da Costa
Michael Gmelin <free...@grem.de> writes:

> While debugging an unexpected assertion problem, I noticed that ports
> using cmake don't set -NDEBUG, even when building in Release mode.
>
> Is this intentional?

Is it the software you're porting that checks for DEBUG or some library
it uses?

CMake code should check for CMAKE_BUILD_TYPE and adjust the compiler
flags accordingly (if at all); so if the software itself is checking for
DEBUG but not passing (or omitting it) I'd say the bug is there, not in
Mk/Uses/cmake.mk.
___
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"


cmake release builds don't disable assertions (NDEBUG)

2017-02-06 Thread Michael Gmelin
While debugging an unexpected assertion problem, I noticed that ports
using cmake don't set -NDEBUG, even when building in Release mode.

Is this intentional?

Thanks,
Michael

-- 
Michael Gmelin
___
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: Patch to cmake detect OpenMP

2016-09-20 Thread Otacílio de Araújo Ramos Neto
Em ter, 20 de set de 2016 04:04, Matthieu Volat <ma...@alkumuna.eu>
escreveu:

> On Tue, 20 Sep 2016 00:55:44 -0300
> Otacílio <otacilio.n...@bsd.com.br> wrote:
>
> > I'm trying to port flann (http://www.cs.ubc.ca/research/flann/) to
> > FreeBSD, but I need that cmake detects OpenMP. Unhappy, cmake do not
> > detects OpenMP even when devel/openmp is installed,  so I did this patch
> > to cmake port. What you guys think about? Can I open a bug report with
> > patch?
> >
> > []'s
> >
>
> Hi, are you planning to submit this patch for cmake in ports or the
> upstream project?
>
> This is not a really good idea to hardcode /usr/local like that, for there
> can be may more providers for libomp (lang/clangXY ports, if you need a
> specific to workaround bugs for example... or even maybe base in the
> future?). Also, it would break cmake with GCC.
>
> Without changing any upstream code in either cmake or flann, for FreeBSD
> 11+, you can just set :
>
>   USES+=  compiler:openmp
>   CFLAGS+= -I${LOCALBASE}/include
>   LDFLAGS+= -L${LOCALBASE}/lib -lomp -lm
>
> I did not test how this behave on older release yet... And if you need to
> build cmake-based projects outside ports, here's the flags I use:
>
>  -DCMAKE_REQUIRED_INCLUDES="/usr/local/include" \
>  -DCMAKE_REQUIRED_LIBRARIES="-L/usr/local/lib -lomp -lm" \
>  -DCMAKE_EXE_LINKER_FLAGS="-L/usr/local/lib -lomp -lm" \
>  -DCMAKE_MODULE_LINKER_FLAGS="-L/usr/local/lib -lomp -lm" \
>  -DCMAKE_SHARED_LINKER_FLAGS="-L/usr/local/lib -lomp -lm"
>
> -- Matthieu Volat <ma...@alkumuna.eu>
>

Hi Matthieu.

I was planning to submit this patch in ports but, after yours appointments,
I have declined from the idea. My motivation was  that if cmake proposes
find OpenMP it must find OpenMP. But, my patch is not the right procedure
to do it.

[]'s
-Otacilio

>
___
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: Patch to cmake detect OpenMP

2016-09-20 Thread Matthieu Volat
On Tue, 20 Sep 2016 00:55:44 -0300
Otacílio <otacilio.n...@bsd.com.br> wrote:

> I'm trying to port flann (http://www.cs.ubc.ca/research/flann/) to 
> FreeBSD, but I need that cmake detects OpenMP. Unhappy, cmake do not 
> detects OpenMP even when devel/openmp is installed,  so I did this patch 
> to cmake port. What you guys think about? Can I open a bug report with 
> patch?
> 
> []'s
> 

Hi, are you planning to submit this patch for cmake in ports or the upstream 
project?

This is not a really good idea to hardcode /usr/local like that, for there can 
be may more providers for libomp (lang/clangXY ports, if you need a specific to 
workaround bugs for example... or even maybe base in the future?). Also, it 
would break cmake with GCC.

Without changing any upstream code in either cmake or flann, for FreeBSD 11+, 
you can just set :

  USES+=  compiler:openmp 
  CFLAGS+= -I${LOCALBASE}/include
  LDFLAGS+= -L${LOCALBASE}/lib -lomp -lm

I did not test how this behave on older release yet... And if you need to build 
cmake-based projects outside ports, here's the flags I use:

 -DCMAKE_REQUIRED_INCLUDES="/usr/local/include" \
 -DCMAKE_REQUIRED_LIBRARIES="-L/usr/local/lib -lomp -lm" \
 -DCMAKE_EXE_LINKER_FLAGS="-L/usr/local/lib -lomp -lm" \
 -DCMAKE_MODULE_LINKER_FLAGS="-L/usr/local/lib -lomp -lm" \
 -DCMAKE_SHARED_LINKER_FLAGS="-L/usr/local/lib -lomp -lm"

-- Matthieu Volat <ma...@alkumuna.eu>


pgpPnOxTm0Xcz.pgp
Description: OpenPGP digital signature


Patch to cmake detect OpenMP

2016-09-19 Thread Otacílio
I'm trying to port flann (http://www.cs.ubc.ca/research/flann/) to 
FreeBSD, but I need that cmake detects OpenMP. Unhappy, cmake do not 
detects OpenMP even when devel/openmp is installed,  so I did this patch 
to cmake port. What you guys think about? Can I open a bug report with 
patch?


[]'s

-Otacilio

--- Modules/FindOpenMP.cmake.orig2016-09-20 03:52:10 UTC
+++ Modules/FindOpenMP.cmake
@@ -134,8 +134,8 @@ if(CMAKE_C_COMPILER_LOADED)
   endif()

   foreach(FLAG IN LISTS OpenMP_C_FLAG_CANDIDATES)
-set(SAFE_CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS}")
-set(CMAKE_REQUIRED_FLAGS "${FLAG}")
+set(SAFE_CMAKE_REQUIRED_FLAGS "-I/usr/local/include 
-L/usr/local/lib -lm ${CMAKE_REQUIRED_FLAGS}")
+set(CMAKE_REQUIRED_FLAGS "-I/usr/local/include -L/usr/local/lib -lm 
${FLAG}")

 unset(OpenMP_FLAG_DETECTED CACHE)
 if(NOT CMAKE_REQUIRED_QUIET)
   message(STATUS "Try OpenMP C flag = [${FLAG}]")
@@ -148,7 +148,7 @@ if(CMAKE_C_COMPILER_LOADED)
 endif()
   endforeach()

-  set(OpenMP_C_FLAGS "${OpenMP_C_FLAGS_INTERNAL}"
+  set(OpenMP_C_FLAGS "-I/usr/local/include ${OpenMP_C_FLAGS_INTERNAL}"
 CACHE STRING "C compiler flags for OpenMP parallization")

   list(APPEND _OPENMP_REQUIRED_VARS OpenMP_C_FLAGS)
@@ -170,8 +170,8 @@ if(CMAKE_CXX_COMPILER_LOADED)
   endif()

   foreach(FLAG IN LISTS OpenMP_CXX_FLAG_CANDIDATES)
-set(SAFE_CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS}")
-set(CMAKE_REQUIRED_FLAGS "${FLAG}")
+set(SAFE_CMAKE_REQUIRED_FLAGS "-I/usr/local/include 
-L/usr/local/lib ${CMAKE_REQUIRED_FLAGS}")
+set(CMAKE_REQUIRED_FLAGS "-I/usr/local/include -L/usr/local/lib 
${FLAG}")

 unset(OpenMP_FLAG_DETECTED CACHE)
 if(NOT CMAKE_REQUIRED_QUIET)
   message(STATUS "Try OpenMP CXX flag = [${FLAG}]")
@@ -184,7 +184,7 @@ if(CMAKE_CXX_COMPILER_LOADED)
 endif()
   endforeach()

-  set(OpenMP_CXX_FLAGS "${OpenMP_CXX_FLAGS_INTERNAL}"
+  set(OpenMP_CXX_FLAGS "-I/usr/local/include ${OpenMP_CXX_FLAGS_INTERNAL}"
 CACHE STRING "C++ compiler flags for OpenMP parallization")

   list(APPEND _OPENMP_REQUIRED_VARS OpenMP_CXX_FLAGS)

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


cmake and rpath problems

2016-05-22 Thread Diane Bruce
This is a heads up about a bug some of you have run into
and I've reported here.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120

To summarize: any binary or .so object linked using cmake will indeed
have a DT_RPATH entry, but it gets stripped out on install.

I worked around this with comms/sdr-wspr
by stripping the Fortran Flags to determine the RPATH and setting it
manually in CMakeLists.txt

+# temporary ugly hack
+string(REGEX MATCH "-rpath=.*" CMAKE_RPATH_ARG ${CMAKE_Fortran_FLAGS} )
+string(SUBSTRING ${CMAKE_RPATH_ARG} 7 -1 CMAKE_RPATH)
+set(CMAKE_INSTALL_RPATH ${CMAKE_RPATH} )

I know other ports have run into this.

Diane
-- 
- 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: Making a port - debugging cmake check_include_file

2016-04-24 Thread abi

You mean that the checks are passed, but actual support of V4L - is not?
V4L is the optional feature, so lack of it is not a critical error. From 
what I see in cmake files is that header files are detected and several 
knobs are set.
Should I check that these headers somehow used ? I don't have local or 
analog video cameras :(
Or, assuming that if header files are detected and included, failure to 
include them in compilation phase will lead to fatal error, I shouldn't 
bother?


On 24.04.2016 12:59, Matthew D. Fuller wrote:

On Sun, Apr 24, 2016 at 12:48:58PM +0300 I heard the voice of
abi, and lo! it spake thus:

I passed -DCMAKE_REQUIRED_INCLUDES:STRING="${LOCALBASE}/include" from
port Makefile.
Looks like the best solution - no need to poke upstream or make patch.

Interesting.  It's not clear from the docs that
CMAKE_REQUIRED_INCLUDES affects the actual build of the program (or
anything except the check_include_file() from a look around,
actually).  Well, if it works...




___
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: Making a port - debugging cmake check_include_file

2016-04-24 Thread Matthew D. Fuller
On Sun, Apr 24, 2016 at 12:48:58PM +0300 I heard the voice of
abi, and lo! it spake thus:
>
> I passed -DCMAKE_REQUIRED_INCLUDES:STRING="${LOCALBASE}/include" from 
> port Makefile.
> Looks like the best solution - no need to poke upstream or make patch.

Interesting.  It's not clear from the docs that
CMAKE_REQUIRED_INCLUDES affects the actual build of the program (or
anything except the check_include_file() from a look around,
actually).  Well, if it works...


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
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: Making a port - debugging cmake check_include_file

2016-04-24 Thread abi
I passed -DCMAKE_REQUIRED_INCLUDES:STRING="${LOCALBASE}/include" from 
port Makefile.

Looks like the best solution - no need to poke upstream or make patch.

On 24.04.2016 12:43, Matthew D. Fuller wrote:

On Sun, Apr 24, 2016 at 12:09:53PM +0300 I heard the voice of
abi, and lo! it spake thus:

On 24.04.2016 12:00, Matthew D. Fuller wrote:

  get_property(idirs DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} PROPERTY 
INCLUDE_DIRECTORIES)
  set(CMAKE_REQUIRED_INCLUDES ${idirs})

seems like it might do the trick.

Nope, the same behavior.

Did you add those along with and after the EXTRA_INCDIRS stuff?  Else
the extra bits wouldn't have been stuck into INCLUDE_DIRECTORIES yet.



Is hardcoded directory includes considered evil and I should find
(read - ask here :)) ) better solution ?

LOCALBASE != /usr/local is liable to be pretty rare, but I think it's
still theoretically supported, so...




___
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: Making a port - debugging cmake check_include_file

2016-04-24 Thread Matthew D. Fuller
On Sun, Apr 24, 2016 at 12:09:53PM +0300 I heard the voice of
abi, and lo! it spake thus:
> On 24.04.2016 12:00, Matthew D. Fuller wrote:
> >  get_property(idirs DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} PROPERTY 
> > INCLUDE_DIRECTORIES)
> >  set(CMAKE_REQUIRED_INCLUDES ${idirs})
> >
> > seems like it might do the trick.
>
> Nope, the same behavior.

Did you add those along with and after the EXTRA_INCDIRS stuff?  Else
the extra bits wouldn't have been stuck into INCLUDE_DIRECTORIES yet.


> Is hardcoded directory includes considered evil and I should find
> (read - ask here :)) ) better solution ?

LOCALBASE != /usr/local is liable to be pretty rare, but I think it's
still theoretically supported, so...


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
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: Making a port - debugging cmake check_include_file

2016-04-24 Thread abi

Nope, the same behavior.
ZM has OS detection block, I added there
set(CMAKE_REQUIRED_INCLUDES "/usr/include" "/usr/local/include") if 
system is BSD.


Now I have
-- Looking for libv4l1-videodev.h
-- Looking for libv4l1-videodev.h - found
-- Looking for linux/videodev2.h
-- Looking for linux/videodev2.h - found

and tests are passed/entire project is builded. Is hardcoded directory 
includes considered evil and I should find (read - ask here :)) ) better 
solution ?


On 24.04.2016 12:00, Matthew D. Fuller wrote:

On Sun, Apr 24, 2016 at 11:44:31AM +0300 I heard the voice of
abi, and lo! it spake thus:

I go the first way, however it seems that include directory is ignored
in include tests.

Oh, right.  That's annoying.



Should I try CMAKE_REQUIRED_INCLUDES ? However, I don't know the
effect of this on linux systems.

I'd skip worrying about that for now.  Get a patch working for the
port, then worry later about if/how to upstream it.

 get_property(idirs DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} PROPERTY 
INCLUDE_DIRECTORIES)
 set(CMAKE_REQUIRED_INCLUDES ${idirs})

seems like it might do the trick.




___
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: Making a port - debugging cmake check_include_file

2016-04-24 Thread Matthew D. Fuller
On Sun, Apr 24, 2016 at 11:44:31AM +0300 I heard the voice of
abi, and lo! it spake thus:
>
> I go the first way, however it seems that include directory is ignored 
> in include tests.

Oh, right.  That's annoying.


> Should I try CMAKE_REQUIRED_INCLUDES ? However, I don't know the
> effect of this on linux systems.

I'd skip worrying about that for now.  Get a patch working for the
port, then worry later about if/how to upstream it.

get_property(idirs DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} PROPERTY 
INCLUDE_DIRECTORIES)
set(CMAKE_REQUIRED_INCLUDES ${idirs})

seems like it might do the trick.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
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: Making a port - debugging cmake check_include_file

2016-04-24 Thread abi
I go the first way, however it seems that include directory is ignored 
in include tests.

-- Found PkgConfig: /usr/local/bin/pkg-config (found version "0.28")
-- Checking for module 'libv4l1'
--   Found libv4l1, version 1.6.3

gmake[3]: Entering directory 
'/usr/home/abishai/zoneminder/work/ZoneMinder-5a3978f/CMakeFiles/CMakeTmp'

Building C object CMakeFiles/cmTC_c7b01.dir/CheckIncludeFile.c.o
/usr/bin/cc-O2 -pipe  -fstack-protector -fno-strict-aliasing -o 
CMakeFiles/cmTC_c7b01.dir/CheckIncludeFile.c.o   -c 
/usr/home/abishai/zoneminder/work/ZoneMinder-5a3978f/CMakeFiles/CMakeTmp/CheckIncludeFile.c
/usr/home/abishai/zoneminder/work/ZoneMinder-5a3978f/CMakeFiles/CMakeTmp/CheckIncludeFile.c:1:10: 
fatal error: 'libv4l1-videodev.h' file not found

#include 

No -I, like before.
Should I try CMAKE_REQUIRED_INCLUDES ? However, I don't know the effect 
of this on linux systems.



On 24.04.2016 10:13, Matthew D. Fuller wrote:

On Sun, Apr 24, 2016 at 01:28:35AM +0300 I heard the voice of
abi, and lo! it spake thus:

Thanks!
If speak about general purpose solution, acceptable by upstream, I should
1. make cmake variable like INCLUDE_DIR_EXTRA
2. if set, include it contents.
3. add default value if platform is FreeBSD
Am I right?

I'd say it depends on how much work you wanna put in, and how
interested upstream is.


The pkgconfig path is fairly simple.  In a quick test:

 include(FindPkgConfig)
 pkg_check_modules(LIBV4L1 libv4l1)
 if(LIBV4L1_FOUND)
 include_directories(${LIBV4L1_INCLUDE_DIRS})
 endif()

seems to set things right here (I assume from the libv4l1-videodev.h
that it wants v4l_1_ rather than v4l_2_).  That may be trivially
upstreamable, since it should just quietly have no effect in the cases
where v4l isn't in pkgconf, and DTRT when it is.  Of course, it won't
work if a system doesn't have pkg-config installed, so unless you
wanted to add that as a build dep (it _is_ pretty tiny, but it's an
extra dep), you couldn't assume it was there on the system.


A somewhat more verbose solution that passes more control to the port
level would be to patch in a block like

 if(EXTRA_INCDIRS)
 foreach(dir ${EXTRA_INCDIRS})
 include_directories(${dir})
 endforeach()
 endif()

relatively early into the CMakeLists.txt and then add $LOCALBASE into
the cmake command with something like

 CMAKE_ARGS+=-DEXTRA_INCDIRS="${LOCALBASE}"

in the port Makefile (untested).  Aside from potential need to redo
the patch if the CMakeLists.txt changes between releases, that doesn't
really need any upstream involvement at all, it can just be carried in
the port.  OTOH, it's probably not too objectionable (possibly with
tweaks to variable naming) to upstream either.





___
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: Making a port - debugging cmake check_include_file

2016-04-23 Thread abi

Thanks!
If speak about general purpose solution, acceptable by upstream, I should
1. make cmake variable like INCLUDE_DIR_EXTRA
2. if set, include it contents.
3. add default value if platform is FreeBSD
Am I right?

On 24.04.2016 00:55, Matthew D. Fuller wrote:

On Sat, Apr 23, 2016 at 11:51:00PM +0300 I heard the voice of
abi, and lo! it spake thus:

/usr/bin/cc-O2 -pipe  -fstack-protector -fno-strict-aliasing -o
CMakeFiles/cmTC_bd985.dir/CheckIncludeFile.c.o   -c
/usr/home/abishai/zoneminder/work/ZoneMinder-5a3978f/CMakeFiles/CMakeTmp/CheckIncludeFile.c
/usr/home/abishai/zoneminder/work/ZoneMinder-5a3978f/CMakeFiles/CMakeTmp/CheckIncludeFile.c:1:10:
fatal error: 'libv4l1-videodev.h' file not found
#include 
   ^
1 error generated.

Note lack of -I/usr/local/include in the command.  So cmake isn't
looking there.  You'd need to somehow get that in the list.

Of course, it'd actually be spelled $LOCALBASE, presumably.  Actually,
libv4l does install pkgconf stuff, so if the cmake process could be
tweaked to pull that in, that may be the "best" solution.  Look at the
FindPkgConfig module in cmake
(https://cmake.org/cmake/help/v3.5/module/FindPkgConfig.html).

Of course, that does mean doing a fair amount more surgery in the
CMakeFile.  Simpler may just be to pass $LOCALBASE in via CMAKE_ARGS
and then manually add that via include_directories().





___
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: Making a port - debugging cmake check_include_file

2016-04-23 Thread Matthew D. Fuller
On Sat, Apr 23, 2016 at 11:51:00PM +0300 I heard the voice of
abi, and lo! it spake thus:
> 
> /usr/bin/cc-O2 -pipe  -fstack-protector -fno-strict-aliasing -o 
> CMakeFiles/cmTC_bd985.dir/CheckIncludeFile.c.o   -c 
> /usr/home/abishai/zoneminder/work/ZoneMinder-5a3978f/CMakeFiles/CMakeTmp/CheckIncludeFile.c
> /usr/home/abishai/zoneminder/work/ZoneMinder-5a3978f/CMakeFiles/CMakeTmp/CheckIncludeFile.c:1:10:
>  
> fatal error: 'libv4l1-videodev.h' file not found
> #include 
>   ^
> 1 error generated.

Note lack of -I/usr/local/include in the command.  So cmake isn't
looking there.  You'd need to somehow get that in the list.

Of course, it'd actually be spelled $LOCALBASE, presumably.  Actually,
libv4l does install pkgconf stuff, so if the cmake process could be
tweaked to pull that in, that may be the "best" solution.  Look at the
FindPkgConfig module in cmake
(https://cmake.org/cmake/help/v3.5/module/FindPkgConfig.html).

Of course, that does mean doing a fair amount more surgery in the
CMakeFile.  Simpler may just be to pass $LOCALBASE in via CMAKE_ARGS
and then manually add that via include_directories().



-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
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"


Making a port - debugging cmake check_include_file

2016-04-23 Thread abi

Hello.

I'm porting Zoneminder, however I have bad luck compiling v4l support.
The program uses smale and has the following check:

check_include_file("libv4l1-videodev.h" HAVE_LIBV4L1_VIDEODEV_H)
if(NOT HAVE_LIBV4L1_VIDEODEV_H)
check_include_file("linux/videodev.h" HAVE_LINUX_VIDEODEV_H)
endif(NOT HAVE_LIBV4L1_VIDEODEV_H)
check_include_file("linux/videodev2.h" HAVE_LINUX_VIDEODEV2_H)

this block failing me completely.

from cmake error log:
Determining if the include file libv4l1-videodev.h exists failed with 
the following output:
Change Dir: 
/usr/home/abishai/zoneminder/work/ZoneMinder-5a3978f/CMakeFiles/CMakeTmp


Run Build Command:"/usr/local/bin/gmake" "cmTC_bd985/fast"
gmake[2]: Entering directory 
'/usr/home/abishai/zoneminder/work/ZoneMinder-5a3978f/CMakeFiles/CMakeTmp'
/usr/local/bin/gmake -f CMakeFiles/cmTC_bd985.dir/build.make 
CMakeFiles/cmTC_bd985.dir/build
gmake[3]: Entering directory 
'/usr/home/abishai/zoneminder/work/ZoneMinder-5a3978f/CMakeFiles/CMakeTmp'

Building C object CMakeFiles/cmTC_bd985.dir/CheckIncludeFile.c.o
/usr/bin/cc-O2 -pipe  -fstack-protector -fno-strict-aliasing -o 
CMakeFiles/cmTC_bd985.dir/CheckIncludeFile.c.o   -c 
/usr/home/abishai/zoneminder/work/ZoneMinder-5a3978f/CMakeFiles/CMakeTmp/CheckIncludeFile.c
/usr/home/abishai/zoneminder/work/ZoneMinder-5a3978f/CMakeFiles/CMakeTmp/CheckIncludeFile.c:1:10: 
fatal error: 'libv4l1-videodev.h' file not found

#include 
 ^
1 error generated.
CMakeFiles/cmTC_bd985.dir/build.make:65: recipe for target 
'CMakeFiles/cmTC_bd985.dir/CheckIncludeFile.c.o' failed

gmake[3]: *** [CMakeFiles/cmTC_bd985.dir/CheckIncludeFile.c.o] Error 1
gmake[3]: Leaving directory 
'/usr/home/abishai/zoneminder/work/ZoneMinder-5a3978f/CMakeFiles/CMakeTmp'

Makefile:126: recipe for target 'cmTC_bd985/fast' failed
gmake[2]: *** [cmTC_bd985/fast] Error 2
gmake[2]: Leaving directory 
'/usr/home/abishai/zoneminder/work/ZoneMinder-5a3978f/CMakeFiles/CMakeTmp'


I have this header file:
abishai@freezm:~/zoneminder % ls -la /usr/local/include/ | grep 
libv4l1-videodev.h

-rw-r--r--   1 root  wheel   7135 Apr 23 23:13 libv4l1-videodev.h

Any ideas ? path problem?
___
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: Error Building devel/cmake

2015-09-25 Thread Amit Sengupta
Many thanks, Walter for sending me the patch for the devel/cmake Makefile.
Unfortunately it didnt solve the issue for me. I was sure the issue was
with some other port on which cmake depends rather than cmake itself. So I
looked up the supporting ports and built them individually and sure enough
it got stuck on ftp/curl because of the new way of handling the default
version of perl (issue 20150914 in UPDATING) . ftp/curl was using perl5.16
which was conflicting with another version already installed. So anyway to
cut a long story short, I cleared out all the ports in my system  and built
them again with portmaster. devel/cmake also compiled fine and now I have
no problems.
___
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: Error Building devel/cmake

2015-09-18 Thread Amit Sengupta
Thanks for the inputs Walter. I will run the patch and let you know how it
goes.
___
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: Error Building devel/cmake

2015-09-16 Thread Amit Sengupta
I did a make clean install and I have confirmed that I do not have
cmake-gui installed.
___
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: Error Building devel/cmake

2015-09-16 Thread Walter Schwarzenfeld

Sorry, overlooked:

Please, change

--- cmake/Makefile to --- Makefile  

___
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: Error Building devel/cmake

2015-09-16 Thread Walter Schwarzenfeld

Hallo !

If I try to compile it, I also got the warnings but it installs fine.
Today there was a update and I updatet to 3.3.1.
I had make a patch - now I had no warnings, and I hope it will help you. 
(If the maintainer said nothing against).


greetings
W.S.
--- cmake/Makefile  2015-09-16 17:37:04 UTC
+++ Makefile
@@ -32,11 +32,15 @@ LIB_DEPENDS=libcurl.so:${PORTSDIR}/ftp/
libexpat.so:${PORTSDIR}/textproc/expat2 \
libjsoncpp.so:${PORTSDIR}/devel/jsoncpp
 RUN_DEPENDS=   
${LOCALBASE}/share/cmake/Modules/CMake.cmake:${PORTSDIR}/devel/cmake-modules
+.endif
+.include 
 
+.if ${PORT_OPTIONS:MMANPAGES}
 MANPAGES_BUILD_DEPENDS=sphinx-build:${PORTSDIR}/textproc/py-sphinx
 MANPAGES_CONFIGURE_ON= --sphinx-man
 .endif
 
+
 .include 
 
 .if defined(STRIP) && ${STRIP} != "" && !defined(WITH_DEBUG)
@@ -60,7 +64,7 @@ post-patch:
 
 # cmake-gui(1) is installed by devel/cmake-gui. Remove the man page's source to
 # prevent it from being built/installed by devel/cmake.
-   ${RM} ${WRKSRC}/Help/manual/cmake-gui.1.rst
+#  ${RM} ${WRKSRC}/Help/manual/cmake-gui.1.rst
 
 .if !defined(CMAKE_MODULES)
 post-install:
___
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: Error Building devel/cmake

2015-09-15 Thread Amit Sengupta
Sorry tried both the options that you suggested:

1.Comment line 63 in Makefile
2.Uncheck all options in make config

Same result as before.
___
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: Error Building devel/cmake

2015-09-15 Thread Walter Schwarzenfeld

Sorry, should be cmake-gui...
___
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: Error Building devel/cmake

2015-09-15 Thread Walter Schwarzenfeld

there was something wrong in the clipboard
citation should be

>Same result as before
___
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: Error Building devel/cmake

2015-09-15 Thread Walter Schwarzenfeld

Hallo !!
>

svnlite co https://svn0.us-east.freebsd.org/ports/head/

Cannot be!

Either you have installed amake-gui or you forget run make clean before next 
try.

___
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: Error Building devel/cmake

2015-09-15 Thread Walter Schwarzenfeld

Sorry, should be cmake-gui...
___
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"


Error Building devel/cmake

2015-09-14 Thread Amit Sengupta
Stuck with an error while building devel/cmake from ports. It always stops
at :

None:None: WARNING: cmake:manual reference target not found: cmake-gui(1)
None:None: WARNING: cmake:manual reference target not found: cmake-gui(1)
[100%] Built target documentation
===>  Staging for cmake-3.3.1
===>   Generating temporary packing list
[  8%] Built target cmsys
[ 11%] Built target cmsys_c
[ 11%] Built target cmcompress
[ 61%] Built target CMakeLib
[ 69%] Built target CPackLib
[ 89%] Built target CTestLib
[ 95%] Built target ccmake
[ 97%] Built target cmake
[ 98%] Built target cpack
[ 99%] Built target ctest
[100%] sphinx-build man: see Utilities/Sphinx/build-man.log
/usr/ports/devel/cmake/work/cmake-3.3.1/Help/index.rst:16: WARNING: toctree
contains reference to nonexisting document u'manual/cmake-gui.1'
None:None: WARNING: cmake:manual reference target not found: cmake-gui(1)
None:None: WARNING: cmake:manual reference target not found: cmake-gui(1)
None:None: WARNING: cmake:manual reference target not found: cmake-gui(1)
None:None: WARNING: cmake:manual reference target not found: cmake-gui(1)
None:None: WARNING: cmake:manual reference target not found: cmake-gui(1)
None:None: WARNING: cmake:manual reference target not found: cmake-gui(1)
None:None: WARNING: cmake:manual reference target not found: cmake-gui(1)
[100%] Built target documentation
Installing the project stripped...
*** Signal 11

Stop.
make[2]: stopped in /usr/ports/devel/cmake/work/cmake-3.3.1
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/devel/cmake
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/cmake

===>>> make stage failed for devel/cmake
===>>> Aborting update


===>>> You can restart from the point of failure with this command line:
   portmaster  devel/cmake devel/cmake-modules

It was suggested in the freebsd forum that an issue in py27-sphinx was
causing the problem. I rebuilt that as well but same error. I also tried
make rmconfig. No luck.

I am using 10.1 RELEASE:

FreeBSD unixmaster 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11
22:51:51 UTC 2014
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC
i386


Any help is welcome.
___
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: Error Building devel/cmake

2015-09-14 Thread Raphael Kubo da Costa
Amit Sengupta <sengupta.a...@gmail.com> writes:

> [100%] Built target documentation
> Installing the project stripped...
> *** Signal 11

Something has crashed, but it's not clear what. Can you add --verbose to
CONFIGURE_ARGS in devel/cmake/Makefile and rebuild? Do you get any core
dumps with this crash?

___
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: Error Building devel/cmake

2015-09-14 Thread Walter Schwarzenfeld

Hallo !

If you not want to install cmake-gui, comment out line 63 in the Makefile:
63 #${RM} ${WRKSRC}/Help/manual/cmake-gui.1.rst
(But now you can't install cmake-gui this will conflicting the manpage).

Or you compile it with  options DOCS and MANPAGES set to off.

greetings
Walter Schwarzenfeld
___
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: Error Building devel/cmake

2015-09-14 Thread Walter Schwarzenfeld



On 14.09.2015 20:27, Walter Schwarzenfeld wrote:

Hallo !

If you not want to install cmake-gui, comment out line 63 in the 
Makefile:

63 #${RM} ${WRKSRC}/Help/manual/cmake-gui.1.rst
(But now you can't install cmake-gui this will conflicting the manpage).

Or you compile it with  options DOCS and MANPAGES set to off.

greetings
Walter Schwarzenfeld
___
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"



If you not want to install cmake-gui, comment out line 63 in the Makefile:
63 #${RM} ${WRKSRC}/Help/manual/cmake-gui.1.rst
(But now you can't install cmake-gui this will conflicting the manpage).

Or you compile it with  options DOCS and MANPAGES set to off.
___
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"


cmake fails if OSVERSION set in /etc/make.conf

2015-07-29 Thread Ben Woods
Hi everyone,

Yesterday I was having difficulty building a port in a jailed
environment (I am using iocage to create a FreeBSD 10.1 amd64 jail).

After a fair bit of investigation, suspecting either the port or clang
to be at fault due to the error message, I realised that cmake fails
to build a port if OSVERSION is set in /etc/make.conf.

I am confident it is not a problem with the port, as I have seen this
error message in two separate ports (output of trying to build lang/io
and science/InsightToolkit is below).

Why did I have OSVERSION set? I can't remember exactly why, but I must
have been having a problem building ports in the FreeBSD 10.1 jail on
my FreeBSD current host, and would have followed the advice in this
notice in /usr/ports/CHANGES:

20140930:
AUTHOR: bdrew...@freebsd.org

 Building ports in a chroot or jail have always required a particular
 environment be setup. This was not clear though and the ports framework
 did not enforce it. These requirements are:
 1. Either a SRC_BASE/sys/sys/param.h, or /usr/include/sys/param.h be
 present with the __FreeBSD_version_ number of the target system,
 or OSVERSION be set in the environment. Lack of these would fallback
 on kern.osreldate before, which is no longer the case.
 2. UNAME_r,UNAME_v,UNAME_s all must be set for the target system.

 Not having these values in sync will now cause the build to error until it is
 resolved.

 Setting these in the environment can be done via your own wrapper scripts,
 or /etc/login.conf (along with cap_mkdb /etc/login.conf) or
 via /etc/make.conf using appropriate values. Note that OSVERSION is redundant
 if a proper param.h is in the environment:

 OSVERSION+= 1100036
 UNAME_ENV+= OSVERSION=${OSVERSION}
 UNAME_ENV+= UNAME_s=FreeBSD
 UNAME_ENV+= UNAME_r=11.0-CURRENT
 UNAME_ENV+= UNAME_v=${UNAME_s} ${UNAME_r}
 .MAKEFLAGS: ${UNAME_ENV}
 MAKE_ENV+=  ${UNAME_ENV}
 CONFIGURE_ENV+= ${UNAME_ENV}
 SCRIPTS_ENV+=   ${UNAME_ENV}


Has anyone else come across this? What are the thoughts?

Regards,
Ben


*** FULL CONTENTS OF /ETC/MAKE.CONF INSIDE JAIL ***
WRKDIRPREFIX=/var/ports
DISTDIR=/var/ports/distfiles
PACKAGES=/var/ports/packages
INDEXDIR=/var/ports
USE_PACKAGE_DEPENDS_ONLY=yes
DEVELOPER=yes
#WITH_DEBUG=yes
OSVERSION+= 1001000
UNAME_ENV+= OSVERSION=${OSVERSION}
UNAME_ENV+= UNAME_s=FreeBSD
UNAME_ENV+= UNAME_r=10.1-RELEASE
UNAME_ENV+= UNAME_v=${UNAME_s} ${UNAME_r}
.MAKEFLAGS: ${UNAME_ENV}
MAKE_ENV+=  ${UNAME_ENV}
CONFIGURE_ENV+= ${UNAME_ENV}
SCRIPTS_ENV+=   ${UNAME_ENV}




*** OUTPUT WHEN TRYING TO BUILD SCIENCE/INSIGHTTOOLKIT ***
root@jail:/usr/ports/science/InsightToolkit # make
===   InsightToolkit-4.8.0 depends on file: /usr/local/bin/cmake - found
===  Configuring for InsightToolkit-4.8.0
===  Performing out-of-source build
/bin/mkdir -p /var/ports/usr/ports/science/InsightToolkit/work/.build
-- The C compiler identification is Clang 3.4.1
-- The CXX compiler identification is Clang 3.4.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- broken
CMake Error at /usr/local/share/cmake/Modules/CMakeTestCCompiler.cmake:61
(message):
  The C compiler /usr/bin/cc is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: 
/var/ports/usr/ports/science/InsightToolkit/work/.build/CMakeFiles/CMakeTmp



  Run Build Command:/usr/bin/make cmTryCompileExec2149568943/fast

  /usr/bin/make -f CMakeFiles/cmTryCompileExec2149568943.dir/build.make
  CMakeFiles/cmTryCompileExec2149568943.dir/build

  /usr/local/bin/cmake -E cmake_progress_report
  
/var/ports/usr/ports/science/InsightToolkit/work/.build/CMakeFiles/CMakeTmp/CMakeFiles
  1

  Building C object
  CMakeFiles/cmTryCompileExec2149568943.dir/testCCompiler.c.o

  /usr/bin/cc -O2 -pipe -fstack-protector -fno-strict-aliasing -o
  CMakeFiles/cmTryCompileExec2149568943.dir/testCCompiler.c.o -c
  
/var/ports/usr/ports/science/InsightToolkit/work/.build/CMakeFiles/CMakeTmp/testCCompiler.c


  Linking C executable cmTryCompileExec2149568943

  /usr/local/bin/cmake -E cmake_link_script
  CMakeFiles/cmTryCompileExec2149568943.dir/link.txt --verbose=1

  /usr/bin/cc -O2 -pipe -fstack-protector -fno-strict-aliasing
  -fstack-protector
  CMakeFiles/cmTryCompileExec2149568943.dir/testCCompiler.c.o -o
  cmTryCompileExec2149568943



  make[2]: stopped in
  /var/ports/usr/ports/science/InsightToolkit/work/.build/CMakeFiles/CMakeTmp


  make[2]: don't know how to make 1001000.  Stop





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:14 (project)


-- Configuring incomplete, errors occurred!
See also 
/var/ports/usr/ports/science/InsightToolkit/work/.build/CMakeFiles/CMakeOutput.log.
See also 
/var/ports/usr/ports/science/InsightToolkit/work/.build/CMakeFiles/CMakeError.log.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/science/InsightToolkit
*** Error code 1

Stop.
make

Re: devel/cmake fails with Signal 11

2015-07-22 Thread Alex V. Petrov
Agree. On the 10-Stable i386.

22.07.2015 04:43, Rob Belics пишет:
 I tried to update today but received this:
 /usr/ports/devel/cmake/work/cmake-3.2.3/Help/index.rst:16: WARNING: toctree 
 contains reference to nonexisting document u'manual/cmake-gui.1'
 None:None: WARNING: cmake:manual reference target not found: cmake-gui(1)
 None:None: WARNING: cmake:manual reference target not found: cmake-gui(1)
 [100%] Built target documentation
 Installing the project stripped. . .
 *** Signal 11
 
 Stop.
 make[2]: stopped in /usr/ports/devel/cmake/work/cmake-3.2.3
 *** Error code 1
 
 After Googling a bit, I thought the error was caused by sphinx. Portmaster 
 shows sphinx as being py27-sphinx but there is no port in my tree; just 
 py-sphinx. I tried to change the config so it doesn't build with docs or man 
 pages but unchecking the options would not take. I had to uninstall 
 py27-sphinx and py27-sphinx_rtd_theme. 
 
 However, attempting to build with the new config now gives me 
 
 === Staging for cmake-3.2.3_2
 === Generating temporary packing list
 ...
 [100%] Built target ctest
 Installing the project stripped...
 *** Signal 11
 
 Stop.
 make[2]: stopped in /usr/ports/devel/cmake/work/cmake-3.2.3
 *** Error code 1
 
 I had also uninstalled cmake at one time and re-extracted it to no avail. So 
 I'm stuck without cmake right now and don't know what to do.
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

devel/cmake fails with Signal 11

2015-07-21 Thread Rob Belics
Forgot to mention I was able to update my workstation which runs FreeBSD 
9.3-RELEASE but the box I'm having trouble with is a server running 10.1-RELEASE
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


devel/cmake fails with Signal 11

2015-07-21 Thread Rob Belics
I tried to update today but received this:
/usr/ports/devel/cmake/work/cmake-3.2.3/Help/index.rst:16: WARNING: toctree 
contains reference to nonexisting document u'manual/cmake-gui.1'
None:None: WARNING: cmake:manual reference target not found: cmake-gui(1)
None:None: WARNING: cmake:manual reference target not found: cmake-gui(1)
[100%] Built target documentation
Installing the project stripped. . .
*** Signal 11

Stop.
make[2]: stopped in /usr/ports/devel/cmake/work/cmake-3.2.3
*** Error code 1

After Googling a bit, I thought the error was caused by sphinx. Portmaster 
shows sphinx as being py27-sphinx but there is no port in my tree; just 
py-sphinx. I tried to change the config so it doesn't build with docs or man 
pages but unchecking the options would not take. I had to uninstall 
py27-sphinx and py27-sphinx_rtd_theme. 

However, attempting to build with the new config now gives me 

=== Staging for cmake-3.2.3_2
=== Generating temporary packing list
...
[100%] Built target ctest
Installing the project stripped...
*** Signal 11

Stop.
make[2]: stopped in /usr/ports/devel/cmake/work/cmake-3.2.3
*** Error code 1

I had also uninstalled cmake at one time and re-extracted it to no avail. So 
I'm stuck without cmake right now and don't know what to do.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


devel/cmake fails with Signal 11

2015-07-21 Thread Rob Belics
I'm wondering if this closed bug report is related: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193259
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: FreeBSD Port: devel/cmake - cannot build without py-babel

2015-07-15 Thread Miroslav Lachman

Kris Moore wrote on 07/15/2015 17:27:

On 07/15/2015 10:57, Miroslav Lachman wrote:



The full log is here http://pastebin.com/5MxnT3K5

It worked two weeks ago without babel.

Now Sphinx (py27-Jinja2) requires Babel extension.

Is this intentional?

Miroslav Lachman




Yea, the update to sphinx looks like it needs babel for some
functionality now.

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

I've just commited this fix, let me know if it still fails.


[00:07:22]  Creating pkgng repository
Creating repository in /tmp/packages: 100%
Packing files for repository: 100%
[00:07:23]  Committing packages to repository
[00:07:23]  Removing old packages
[00:07:23]  Built ports: devel/py-pytz devel/py-babel 
textproc/py-sphinx devel/cmake graphics/png graphics/gd net-mgmt/mrtg
[9_3_amd64-default] [2015-07-15_21h23m23s] [committing:] Queued: 7 
Built: 7  Failed: 0  Skipped: 0  Ignored: 0  Tobuild: 0   Time: 00:07:22


It works again.

Thank you for your quick reply and fix in ports tree!

Miroslav Lachman
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: FreeBSD Port: devel/cmake - cannot build without py-babel

2015-07-15 Thread Kris Moore
On 07/15/2015 10:57, Miroslav Lachman wrote:
 Hi,
 cmake cannot be built in my poudriere setup. It always ends with the
 same error (on FreeBSD 8.4 and 10.1)

 [ 99%] Building CXX object Source/CMakeFiles/cpack.dir/CPack/cpack.cxx.o
 Linking CXX executable ../bin/cpack
 [ 99%] Built target cpack
 Scanning dependencies of target ctest
 [ 99%] Building CXX object Source/CMakeFiles/ctest.dir/ctest.cxx.o
 Linking CXX executable ../bin/ctest
 [ 99%] Built target ctest
 Scanning dependencies of target documentation
 [100%] sphinx-build man: see Utilities/Sphinx/build-man.log
 Traceback (most recent call last):
   File /usr/local/bin/sphinx-build, line 5, in module
 from pkg_resources import load_entry_point
   File
 /usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py,
 line 3074, in module
 @_call_aside
   File
 /usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py,
 line 3060, in _call_aside
 f(*args, **kwargs)
   File
 /usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py,
 line 3087, in _initialize_master_working_set
 working_set = WorkingSet._build_master()
   File
 /usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py,
 line 645, in _build_master
 ws.require(__requires__)
   File
 /usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py,
 line 946, in require
 needed = self.resolve(parse_requirements(requirements))
   File
 /usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py,
 line 833, in resolve
 raise DistributionNotFound(req, requirers)
 pkg_resources.DistributionNotFound: The 'babel=1.3' distribution was
 not found and is required by Sphinx
 *** Error code 1

 Stop in /wrkdirs/usr/ports/devel/cmake/work/cmake-3.2.3.
 *** Error code 1

 Stop in /wrkdirs/usr/ports/devel/cmake/work/cmake-3.2.3.
 *** Error code 1

 Stop in /wrkdirs/usr/ports/devel/cmake/work/cmake-3.2.3.
 *** Error code 1

 Stop in /usr/ports/devel/cmake.
  Cleaning up wrkdir
 ===  Cleaning for cmake-3.2.3_1
 build of devel/cmake ended at Wed Jul 15 16:11:15 CEST 2015
 build time: 00:05:20
 !!! build failure encountered !!!



 The full log is here http://pastebin.com/5MxnT3K5

 It worked two weeks ago without babel.

 Now Sphinx (py27-Jinja2) requires Babel extension.

 Is this intentional?

 Miroslav Lachman
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Yea, the update to sphinx looks like it needs babel for some
functionality now.

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

I've just commited this fix, let me know if it still fails.

-- 
Kris Moore
PC-BSD Software / iXsystems
Enterprise Storage  Servers Driven By Open Source

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


FreeBSD Port: devel/cmake - cannot build without py-babel

2015-07-15 Thread Miroslav Lachman

Hi,
cmake cannot be built in my poudriere setup. It always ends with the 
same error (on FreeBSD 8.4 and 10.1)


[ 99%] Building CXX object Source/CMakeFiles/cpack.dir/CPack/cpack.cxx.o
Linking CXX executable ../bin/cpack
[ 99%] Built target cpack
Scanning dependencies of target ctest
[ 99%] Building CXX object Source/CMakeFiles/ctest.dir/ctest.cxx.o
Linking CXX executable ../bin/ctest
[ 99%] Built target ctest
Scanning dependencies of target documentation
[100%] sphinx-build man: see Utilities/Sphinx/build-man.log
Traceback (most recent call last):
  File /usr/local/bin/sphinx-build, line 5, in module
from pkg_resources import load_entry_point
  File 
/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py, line 
3074, in module

@_call_aside
  File 
/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py, line 
3060, in _call_aside

f(*args, **kwargs)
  File 
/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py, line 
3087, in _initialize_master_working_set

working_set = WorkingSet._build_master()
  File 
/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py, line 
645, in _build_master

ws.require(__requires__)
  File 
/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py, line 
946, in require

needed = self.resolve(parse_requirements(requirements))
  File 
/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py, line 
833, in resolve

raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'babel=1.3' distribution was 
not found and is required by Sphinx

*** Error code 1

Stop in /wrkdirs/usr/ports/devel/cmake/work/cmake-3.2.3.
*** Error code 1

Stop in /wrkdirs/usr/ports/devel/cmake/work/cmake-3.2.3.
*** Error code 1

Stop in /wrkdirs/usr/ports/devel/cmake/work/cmake-3.2.3.
*** Error code 1

Stop in /usr/ports/devel/cmake.
 Cleaning up wrkdir
===  Cleaning for cmake-3.2.3_1
build of devel/cmake ended at Wed Jul 15 16:11:15 CEST 2015
build time: 00:05:20
!!! build failure encountered !!!



The full log is here http://pastebin.com/5MxnT3K5

It worked two weeks ago without babel.

Now Sphinx (py27-Jinja2) requires Babel extension.

Is this intentional?

Miroslav Lachman
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: cmake: missing library /usr/local/lib/libjsoncpp.so

2015-06-19 Thread Dr. Peter Voigt
Well, submitted PR 200969:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200969

Peter
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: cmake: missing library /usr/local/lib/libjsoncpp.so

2015-06-18 Thread Dr. Peter Voigt
Sorry for incomplete subject.


On Thu, 18 Jun 2015 08:31:29 +0200
Dr. Peter Voigt pvo...@uos.de wrote:

 When building latest devel/cmake on 10.1-RELEASE-p13 (amd64)
 
 # portmaster --no-confirm --no-term-title -D -G cmake
 
 there is an error about missing library /usr/local/lib/libjsoncpp.so
 
 ...
 
 ===  Installing for cmake-3.2.3
 ===  Checking if cmake already installed
 ===   Registering installation for cmake-3.2.3 as automatic
 (cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/ccmake
 - required shared library /usr/local/lib/libjsoncpp.so not found
 (cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/cmake -
 required shared library /usr/local/lib/libjsoncpp.so not found
 (cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/cpack -
 required shared library /usr/local/lib/libjsoncpp.so not found
 (cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/ctest -
 required shared library /usr/local/lib/libjsoncpp.so not found
 Installing cmake-3.2.3...
 
 === Re-installation of cmake-3.2.3 succeeded
 
 === The following actions were performed:
 Re-installation of cmake-modules-3.2.3
 Re-installation of cmake-3.2.3
 
 However:
 
 # ls -l /usr/local/lib/libjsoncpp*
 -rw-r--r-- 1 root wheel 535316 Jun 17
 20:22 /usr/local/lib/libjsoncpp.a lrwxr-xr-x 1 root wheel 15 Jun
 17 20:22 /usr/local/lib/libjsoncpp.so - libjsoncpp.so.0 -r--r--r-- 1
 root wheel 348376 Jun 17 20:22 /usr/local/lib/libjsoncpp.so.0
 
 Build finished just fine but during installation registration of
 shared libraries failed. This can be verified with pkg:
 
 # pkg check -Bnv cmake   
 [1/1] Checking cmake-3.2.3: shared
 libraries...(cmake-3.2.3) /usr/local/bin/ccmake - required shared
 library /usr/local/lib/libjsoncpp.so not found
 (cmake-3.2.3) /usr/local/bin/cmake - required shared
 library /usr/local/lib/libjsoncpp.so not found
 (cmake-3.2.3) /usr/local/bin/cpack - required shared
 library /usr/local/lib/libjsoncpp.so not found
 (cmake-3.2.3) /usr/local/bin/ctest - required shared
 library /usr/local/lib/libjsoncpp.so not found done
 
 Is this a known issue or should I create a PR?
 
 Peter
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to
 freebsd-ports-unsubscr...@freebsd.org

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


Re: cmake: missing library /usr/local/lib/libjsoncpp.so

2015-06-18 Thread Dewayne Geraghty
On 19/06/2015 8:16 AM, Kevin Oberman wrote:
 On Thu, Jun 18, 2015 at 5:45 AM, Dr. Peter Voigt pvo...@uos.de wrote:

 Sorry for incomplete subject.


 On Thu, 18 Jun 2015 08:31:29 +0200
 Dr. Peter Voigt pvo...@uos.de wrote:

 When building latest devel/cmake on 10.1-RELEASE-p13 (amd64)

 # portmaster --no-confirm --no-term-title -D -G cmake

 there is an error about missing library /usr/local/lib/libjsoncpp.so

 ...

 ===  Installing for cmake-3.2.3
 ===  Checking if cmake already installed
 ===   Registering installation for cmake-3.2.3 as automatic
 (cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/ccmake
 - required shared library /usr/local/lib/libjsoncpp.so not found
 (cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/cmake -
 required shared library /usr/local/lib/libjsoncpp.so not found
 (cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/cpack -
 required shared library /usr/local/lib/libjsoncpp.so not found
 (cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/ctest -
 required shared library /usr/local/lib/libjsoncpp.so not found
 Installing cmake-3.2.3...

 === Re-installation of cmake-3.2.3 succeeded

 === The following actions were performed:
 Re-installation of cmake-modules-3.2.3
 Re-installation of cmake-3.2.3

 However:

 # ls -l /usr/local/lib/libjsoncpp*
 -rw-r--r-- 1 root wheel 535316 Jun 17
 20:22 /usr/local/lib/libjsoncpp.a lrwxr-xr-x 1 root wheel 15 Jun
 17 20:22 /usr/local/lib/libjsoncpp.so - libjsoncpp.so.0 -r--r--r-- 1
 root wheel 348376 Jun 17 20:22 /usr/local/lib/libjsoncpp.so.0

 Build finished just fine but during installation registration of
 shared libraries failed. This can be verified with pkg:

 # pkg check -Bnv cmake
 [1/1] Checking cmake-3.2.3: shared
 libraries...(cmake-3.2.3) /usr/local/bin/ccmake - required shared
 library /usr/local/lib/libjsoncpp.so not found
 (cmake-3.2.3) /usr/local/bin/cmake - required shared
 library /usr/local/lib/libjsoncpp.so not found
 (cmake-3.2.3) /usr/local/bin/cpack - required shared
 library /usr/local/lib/libjsoncpp.so not found
 (cmake-3.2.3) /usr/local/bin/ctest - required shared
 library /usr/local/lib/libjsoncpp.so not found done

 Is this a known issue or should I create a PR?

 Peter
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to
 freebsd-ports-unsubscr...@freebsd.org

 Peter,

 Very odd. You confirm that the file is present, but pkg does not seem to
 know it. I can confirm seeing the same thing, but it is a bogus error as
 rtld can successfully load and run cmake and ldd shows it as resolving
 correctly.. Further, the pkg db does know about it as:
 # pkg which /usr/local/lib/libjsoncpp.so
 /usr/local/lib/libjsoncpp.so was installed by package jsoncpp-0.6.0.r2_1

 It looks like a bug and it affects some people, but it looks most likely
 to be a pkg issue of some sort as the sharable is present and rtld seems
 happy with it.
 --
 Kevin Oberman, Network Engineer, Retired
 E-mail: rkober...@gmail.com
 PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org



Confirmed on (amd64) 10.1S built on 14th June.

Unfortunately on the 10.1S i386 using either clang or gcc;  cmake 3.2.3
doesn't build.

clang

/var/ports/usr/ports/devel/cmake/work/cmake-3.2.3/Source/cmGlobalGenerator.cxx:(.text+0x1237d):
undefined reference to `Json::operator(std::__1::basic_ostreamchar,
std::__1::char_traitschar , Json::Value const)'
c++: error: linker command failed with exit code 1 (use -v to see
invocation)
*** Error code 1


And using lang/gcc

/usr/local/libexec/ccache/gcc48 -O2 -pipe -g0 -ggdb0 -DSTRIP_FBSDID
-march=prescott -mtune=prescott  -Wl,-rpath=/usr/local/lib/gcc48
-fno-strict-aliasing
-I/var/ports/usr/ports/devel/cmake/work/cmake-3.2.3/Bootstrap.cmk
-I/var/ports/usr/ports/devel/cmake/work/cmake-3.2.3/Source  
-I/var/ports/usr/ports/devel/cmake/work/cmake-3.2.3/Bootstrap.cmk
-DKWSYS_NAMESPACE=cmsys  -c
/var/ports/usr/ports/devel/cmake/work/cmake-3.2.3/Source/kwsys/System.c
-o System.o
--- cmGlobalNinjaGenerator.o ---
In file included from
/var/ports/usr/ports/devel/cmake/work/cmake-3.2.3/Source/cmGlobalNinjaGenerator.cxx:14:0:
/var/ports/usr/ports/devel/cmake/work/cmake-3.2.3/Source/cmGeneratorExpressionEvaluationFile.h:39:64:
error: 'mode_t' has not been declared
   std::mapstd::string, std::string outputFiles, mode_t
perm);
^
*** [cmGlobalNinjaGenerator.o] Error code 1

make[1]: stopped in
/var/ports/usr/ports/devel/cmake/work/cmake-3.2.3/Bootstrap.cmk
1 error

The build also fails after the ccache, WRKDIRPREFIX  are cleared.  A
revert to cmake and cmake

Re: cmake: missing library /usr/local/lib/libjsoncpp.so

2015-06-18 Thread Kevin Oberman
On Thu, Jun 18, 2015 at 5:45 AM, Dr. Peter Voigt pvo...@uos.de wrote:

 Sorry for incomplete subject.


 On Thu, 18 Jun 2015 08:31:29 +0200
 Dr. Peter Voigt pvo...@uos.de wrote:

  When building latest devel/cmake on 10.1-RELEASE-p13 (amd64)
 
  # portmaster --no-confirm --no-term-title -D -G cmake
 
  there is an error about missing library /usr/local/lib/libjsoncpp.so
 
  ...
 
  ===  Installing for cmake-3.2.3
  ===  Checking if cmake already installed
  ===   Registering installation for cmake-3.2.3 as automatic
  (cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/ccmake
  - required shared library /usr/local/lib/libjsoncpp.so not found
  (cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/cmake -
  required shared library /usr/local/lib/libjsoncpp.so not found
  (cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/cpack -
  required shared library /usr/local/lib/libjsoncpp.so not found
  (cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/ctest -
  required shared library /usr/local/lib/libjsoncpp.so not found
  Installing cmake-3.2.3...
 
  === Re-installation of cmake-3.2.3 succeeded
 
  === The following actions were performed:
  Re-installation of cmake-modules-3.2.3
  Re-installation of cmake-3.2.3
 
  However:
 
  # ls -l /usr/local/lib/libjsoncpp*
  -rw-r--r-- 1 root wheel 535316 Jun 17
  20:22 /usr/local/lib/libjsoncpp.a lrwxr-xr-x 1 root wheel 15 Jun
  17 20:22 /usr/local/lib/libjsoncpp.so - libjsoncpp.so.0 -r--r--r-- 1
  root wheel 348376 Jun 17 20:22 /usr/local/lib/libjsoncpp.so.0
 
  Build finished just fine but during installation registration of
  shared libraries failed. This can be verified with pkg:
 
  # pkg check -Bnv cmake
  [1/1] Checking cmake-3.2.3: shared
  libraries...(cmake-3.2.3) /usr/local/bin/ccmake - required shared
  library /usr/local/lib/libjsoncpp.so not found
  (cmake-3.2.3) /usr/local/bin/cmake - required shared
  library /usr/local/lib/libjsoncpp.so not found
  (cmake-3.2.3) /usr/local/bin/cpack - required shared
  library /usr/local/lib/libjsoncpp.so not found
  (cmake-3.2.3) /usr/local/bin/ctest - required shared
  library /usr/local/lib/libjsoncpp.so not found done
 
  Is this a known issue or should I create a PR?
 
  Peter
  ___
  freebsd-ports@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-ports
  To unsubscribe, send any mail to
  freebsd-ports-unsubscr...@freebsd.org


Peter,

Very odd. You confirm that the file is present, but pkg does not seem to
know it. I can confirm seeing the same thing, but it is a bogus error as
rtld can successfully load and run cmake and ldd shows it as resolving
correctly.. Further, the pkg db does know about it as:
# pkg which /usr/local/lib/libjsoncpp.so
/usr/local/lib/libjsoncpp.so was installed by package jsoncpp-0.6.0.r2_1

It looks like a bug and it affects some people, but it looks most likely
to be a pkg issue of some sort as the sharable is present and rtld seems
happy with it.
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


cmake:

2015-06-18 Thread Dr. Peter Voigt
When building latest devel/cmake on 10.1-RELEASE-p13 (amd64)

# portmaster --no-confirm --no-term-title -D -G cmake

there is an error about missing library /usr/local/lib/libjsoncpp.so

...

===  Installing for cmake-3.2.3
===  Checking if cmake already installed
===   Registering installation for cmake-3.2.3 as automatic
(cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/ccmake -
required shared library /usr/local/lib/libjsoncpp.so not found
(cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/cmake -
required shared library /usr/local/lib/libjsoncpp.so not found
(cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/cpack -
required shared library /usr/local/lib/libjsoncpp.so not found
(cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/ctest -
required shared library /usr/local/lib/libjsoncpp.so not found
Installing cmake-3.2.3...

=== Re-installation of cmake-3.2.3 succeeded

=== The following actions were performed:
Re-installation of cmake-modules-3.2.3
Re-installation of cmake-3.2.3

However:

# ls -l /usr/local/lib/libjsoncpp*
-rw-r--r-- 1 root wheel 535316 Jun 17 20:22 /usr/local/lib/libjsoncpp.a
lrwxr-xr-x 1 root wheel 15 Jun 17
20:22 /usr/local/lib/libjsoncpp.so - libjsoncpp.so.0 -r--r--r-- 1 root
wheel 348376 Jun 17 20:22 /usr/local/lib/libjsoncpp.so.0

Build finished just fine but during installation registration of shared
libraries failed. This can be verified with pkg:

# pkg check -Bnv cmake   
[1/1] Checking cmake-3.2.3: shared
libraries...(cmake-3.2.3) /usr/local/bin/ccmake - required shared
library /usr/local/lib/libjsoncpp.so not found
(cmake-3.2.3) /usr/local/bin/cmake - required shared
library /usr/local/lib/libjsoncpp.so not found
(cmake-3.2.3) /usr/local/bin/cpack - required shared
library /usr/local/lib/libjsoncpp.so not found
(cmake-3.2.3) /usr/local/bin/ctest - required shared
library /usr/local/lib/libjsoncpp.so not found done

Is this a known issue or should I create a PR?

Peter
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: cmake build failure depending on liblzma

2015-05-03 Thread Raphael Kubo da Costa
Raphael Kubo da Costa rak...@freebsd.org writes:

 Jim Pazarena fpo...@paz.bz writes:

 -- Looking for lzma_auto_decoder in /usr/local/lib/liblzma.so
 -- Looking for lzma_auto_decoder in /usr/local/lib/liblzma.so - not found
 -- Looking for lzma_easy_encoder in /usr/local/lib/liblzma.so
 -- Looking for lzma_easy_encoder in /usr/local/lib/liblzma.so - not found
 -- Looking for lzma_lzma_preset in /usr/local/lib/liblzma.so
 -- Looking for lzma_lzma_preset in /usr/local/lib/liblzma.so - not found
 -- Could NOT find LibLZMA (missing:  LIBLZMA_HAS_AUTO_DECODER
 LIBLZMA_HAS_EASY_ENCODER LIBLZMA_HAS_LZMA_PRESET) (found version
 5.0.5)
 CMake Error at CMakeLists.txt:310 (message):
   CMAKE_USE_SYSTEM_LIBLZMA is ON but LibLZMA is not found!
 Call Stack (most recent call first):
   CMakeLists.txt:488 (CMAKE_BUILD_UTILITIES)

 It should work if you remove archivers/lzmalib, whose liblzma.so is
 being picked up instead of base's liblzma.so.

 It's a workaround, I still need to think of a proper fix. Would you mind
 filing a PR about this?

I've committed a fix in r385307.

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


Re: cmake build failure depending on liblzma

2015-05-01 Thread Raphael Kubo da Costa
Jim Pazarena fpo...@paz.bz writes:

 -- Looking for lzma_auto_decoder in /usr/local/lib/liblzma.so
 -- Looking for lzma_auto_decoder in /usr/local/lib/liblzma.so - not found
 -- Looking for lzma_easy_encoder in /usr/local/lib/liblzma.so
 -- Looking for lzma_easy_encoder in /usr/local/lib/liblzma.so - not found
 -- Looking for lzma_lzma_preset in /usr/local/lib/liblzma.so
 -- Looking for lzma_lzma_preset in /usr/local/lib/liblzma.so - not found
 -- Could NOT find LibLZMA (missing:  LIBLZMA_HAS_AUTO_DECODER
 LIBLZMA_HAS_EASY_ENCODER LIBLZMA_HAS_LZMA_PRESET) (found version
 5.0.5)
 CMake Error at CMakeLists.txt:310 (message):
   CMAKE_USE_SYSTEM_LIBLZMA is ON but LibLZMA is not found!
 Call Stack (most recent call first):
   CMakeLists.txt:488 (CMAKE_BUILD_UTILITIES)

It should work if you remove archivers/lzmalib, whose liblzma.so is
being picked up instead of base's liblzma.so.

It's a workaround, I still need to think of a proper fix. Would you mind
filing a PR about this?

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


Re: cmake build failure depending on liblzma

2015-04-19 Thread Jim Pazarena
just attempted to update another server, and cmake dies on it as well 
citing the same liblzma error


oh my. had better stop with the updates until someone fixes this.



On 2015-04-18 11:14 AM, Jim Pazarena wrote:

I'm attempting a re-install of 10.1 amd, and cmake is a show stopper,
appearing to have a problem with liblzma. I re-installed liblzma, yet
cmake continues to fail. Without cmake many other things such as mysql
fail because of the dependency on cmake.

I am not sure what to do.
Any help would be much appreciated.

Jim


EVIDENCE OF LIBLZMA:

root@servera:~ # cd /usr/local/lib
root@servera:/usr/local/lib # ls -l | grep lzma
-rw-r--r--   1 root  wheel401452 Apr 18 10:44 liblzma.a
lrwxr-xr-x   1 root  wheel16 Apr 18 10:44 liblzma.so -
liblzma.so.1.1.0
lrwxr-xr-x   1 root  wheel16 Apr 18 10:44 liblzma.so.1 -
liblzma.so.1.1
.0
-rwxr-xr-x   1 root  wheel290461 Apr 18 10:44 liblzma.so.1.1.0
root@servera:/usr/local/lib #


FAILURE OF CMAKE:

-- Checking whether cxxabi works with this C++ compiler - yes
-- Using system-installed BZIP2
-- Using system-installed CURL
-- Using system-installed EXPAT
-- Using system-installed LIBARCHIVE
-- Using system-installed LIBLZMA
-- Using system-installed ZLIB
-- Found ZLIB: /usr/lib/libz.so (found version 1.2.8)
-- Found CURL: /usr/local/lib/libcurl.so (found version 7.41.0)
-- Found BZip2: /usr/lib/libbz2.so (found version 1.0.6)
-- Looking for BZ2_bzCompressInit in /usr/lib/libbz2.so
-- Looking for BZ2_bzCompressInit in /usr/lib/libbz2.so - found
-- Looking for lzma_auto_decoder in /usr/local/lib/liblzma.so
-- Looking for lzma_auto_decoder in /usr/local/lib/liblzma.so - not found
-- Looking for lzma_easy_encoder in /usr/local/lib/liblzma.so
-- Looking for lzma_easy_encoder in /usr/local/lib/liblzma.so - not found
-- Looking for lzma_lzma_preset in /usr/local/lib/liblzma.so
-- Looking for lzma_lzma_preset in /usr/local/lib/liblzma.so - not found
-- Could NOT find LibLZMA (missing:  LIBLZMA_HAS_AUTO_DECODER
LIBLZMA_HAS_EASY_ENCODER LIBLZMA_HAS_LZMA_PRESET) (found version 5.0.5)
CMake Error at CMakeLists.txt:310 (message):
   CMAKE_USE_SYSTEM_LIBLZMA is ON but LibLZMA is not found!
Call Stack (most recent call first):
   CMakeLists.txt:488 (CMAKE_BUILD_UTILITIES)


-- Configuring incomplete, errors occurred!
See also
/usr/ports/devel/cmake/work/cmake-3.1.3/CMakeFiles/CMakeOutput.log.
See also
/usr/ports/devel/cmake/work/cmake-3.1.3/CMakeFiles/CMakeError.log.
-
Error when bootstrapping CMake:
Problem while running initial CMake
-
===  Script configure failed unexpectedly.
Please report the problem to k...@freebsd.org [maintainer] and attach the
/usr/ports/devel/cmake/work/cmake-3.1.3/config.log including the
output of
the failure of your make command. Also, it might be a good idea to provide
an overview of all packages installed on your system (e.g. a
/usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/cmake
root@servera:/usr/ports/devel/cmake # ^Dlogout
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

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


cmake build failure depending on liblzma

2015-04-18 Thread Jim Pazarena
I'm attempting a re-install of 10.1 amd, and cmake is a show stopper, 
appearing to have a problem with liblzma. I re-installed liblzma, yet

cmake continues to fail. Without cmake many other things such as mysql
fail because of the dependency on cmake.

I am not sure what to do.
Any help would be much appreciated.

Jim


EVIDENCE OF LIBLZMA:

root@servera:~ # cd /usr/local/lib
root@servera:/usr/local/lib # ls -l | grep lzma
-rw-r--r--   1 root  wheel401452 Apr 18 10:44 liblzma.a
lrwxr-xr-x   1 root  wheel16 Apr 18 10:44 liblzma.so - 
liblzma.so.1.1.0
lrwxr-xr-x   1 root  wheel16 Apr 18 10:44 liblzma.so.1 - 
liblzma.so.1.1

.0
-rwxr-xr-x   1 root  wheel290461 Apr 18 10:44 liblzma.so.1.1.0
root@servera:/usr/local/lib #


FAILURE OF CMAKE:

-- Checking whether cxxabi works with this C++ compiler - yes
-- Using system-installed BZIP2
-- Using system-installed CURL
-- Using system-installed EXPAT
-- Using system-installed LIBARCHIVE
-- Using system-installed LIBLZMA
-- Using system-installed ZLIB
-- Found ZLIB: /usr/lib/libz.so (found version 1.2.8)
-- Found CURL: /usr/local/lib/libcurl.so (found version 7.41.0)
-- Found BZip2: /usr/lib/libbz2.so (found version 1.0.6)
-- Looking for BZ2_bzCompressInit in /usr/lib/libbz2.so
-- Looking for BZ2_bzCompressInit in /usr/lib/libbz2.so - found
-- Looking for lzma_auto_decoder in /usr/local/lib/liblzma.so
-- Looking for lzma_auto_decoder in /usr/local/lib/liblzma.so - not found
-- Looking for lzma_easy_encoder in /usr/local/lib/liblzma.so
-- Looking for lzma_easy_encoder in /usr/local/lib/liblzma.so - not found
-- Looking for lzma_lzma_preset in /usr/local/lib/liblzma.so
-- Looking for lzma_lzma_preset in /usr/local/lib/liblzma.so - not found
-- Could NOT find LibLZMA (missing:  LIBLZMA_HAS_AUTO_DECODER 
LIBLZMA_HAS_EASY_ENCODER LIBLZMA_HAS_LZMA_PRESET) (found version 5.0.5)

CMake Error at CMakeLists.txt:310 (message):
  CMAKE_USE_SYSTEM_LIBLZMA is ON but LibLZMA is not found!
Call Stack (most recent call first):
  CMakeLists.txt:488 (CMAKE_BUILD_UTILITIES)


-- Configuring incomplete, errors occurred!
See also 
/usr/ports/devel/cmake/work/cmake-3.1.3/CMakeFiles/CMakeOutput.log.
See also 
/usr/ports/devel/cmake/work/cmake-3.1.3/CMakeFiles/CMakeError.log.

-
Error when bootstrapping CMake:
Problem while running initial CMake
-
===  Script configure failed unexpectedly.
Please report the problem to k...@freebsd.org [maintainer] and attach the
/usr/ports/devel/cmake/work/cmake-3.1.3/config.log including the output of
the failure of your make command. Also, it might be a good idea to provide
an overview of all packages installed on your system (e.g. a
/usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/cmake
root@servera:/usr/ports/devel/cmake # ^Dlogout
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: upgrading texlive broken due to cmake

2015-01-08 Thread Ben Woods
 Also, I seem to already have py27-Jinja2 2.7.3 installed.

If that is the case, my idea won't help. Not sure what next (some googling
shows similar issues resolved on Mac OS X by reinstalling Python, but I
don't think that will help with freebsd ports).

-- 

--
From: Benjamin Woods
woods...@gmail.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: upgrading texlive broken due to cmake

2015-01-08 Thread Will Parsons
Ben Woods wrote:
 textproc/py-sphinx port depends on the devel/py-Jinja2 port... but the port
 only requires py-Jinja = 2.3.

 Try adding this patch to your ports tree and then retry you build:

 Index: textproc/py-sphinx/Makefile
===
 --- textproc/py-sphinx/Makefile (revision 376204)
 +++ textproc/py-sphinx/Makefile (working copy)
 @@ -14,9 +14,9 @@

  LICENSE=   BSD2CLAUSE

 -BUILD_DEPENDS=
 ${PYTHON_PKGNAMEPREFIX}Jinja2=2.3:${PORTSDIR}/devel/py-Jinja2 \
 +BUILD_DEPENDS=
 ${PYTHON_PKGNAMEPREFIX}Jinja2=2.7:${PORTSDIR}/devel/py-Jinja2 \

 ${PYTHON_PKGNAMEPREFIX}docutils=0.7:${PORTSDIR}/textproc/py-docutils
 -RUN_DEPENDS=
 ${PYTHON_PKGNAMEPREFIX}Jinja2=2.3:${PORTSDIR}/devel/py-Jinja2 \
 +RUN_DEPENDS=
 ${PYTHON_PKGNAMEPREFIX}Jinja2=2.7:${PORTSDIR}/devel/py-Jinja2 \

 ${PYTHON_PKGNAMEPREFIX}docutils=0.7:${PORTSDIR}/textproc/py-docutils \

 ${PYTHON_PKGNAMEPREFIX}pygments=1.2:${PORTSDIR}/textproc/py-pygments

I'm not too familiar with the process of applying patches, so this may
be operator error at my end, but when I attempted to apply your patch,
I got:


Patching file Makefile using Plan A...
patch:  malformed patch at line 51: 
${PYTHON_PKGNAMEPREFIX}Jinja2=2.3:${PORTSDIR}/devel/py-Jinja2 \


Perhaps the patch got mangled when I copied it?

Looking at the patch, it looks like the intent is to replace
Jinja2=2.3 with Jinja2=2.7, so I manually edited the Makefile and then
ran portmaster py27-sphinx, but it did not build:


cd /usr/ports/textproc/py-sphinx/work/Sphinx-1.2.3/build/lib   /usr/bin/env 
PYTHONPATH=/usr/ports/textproc/py-sphinx/work/Sphinx-1.2.3/build/lib:/usr/local/lib/python2.7/site-packages
  /usr/local/bin/python2.7 -m sphinx.pycode.pgen2.driver -c 'import 
load_grammar'
/usr/local/bin/python2.7: No module named jinja2
*** [post-build] Error code 1

Stop in /usr/ports/textproc/py-sphinx.

=== make build failed for textproc/py-sphinx
=== Aborting update



Also, I seem to already have py27-Jinja2-2.7.3 installed.

-- 
Will

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


Re: upgrading texlive broken due to cmake

2015-01-07 Thread Ben Woods
textproc/py-sphinx port depends on the devel/py-Jinja2 port... but the port
only requires py-Jinja = 2.3.

Try adding this patch to your ports tree and then retry you build:

Index: textproc/py-sphinx/Makefile
===
--- textproc/py-sphinx/Makefile (revision 376204)
+++ textproc/py-sphinx/Makefile (working copy)
@@ -14,9 +14,9 @@

 LICENSE=   BSD2CLAUSE

-BUILD_DEPENDS=
${PYTHON_PKGNAMEPREFIX}Jinja2=2.3:${PORTSDIR}/devel/py-Jinja2 \
+BUILD_DEPENDS=
${PYTHON_PKGNAMEPREFIX}Jinja2=2.7:${PORTSDIR}/devel/py-Jinja2 \

${PYTHON_PKGNAMEPREFIX}docutils=0.7:${PORTSDIR}/textproc/py-docutils
-RUN_DEPENDS=
${PYTHON_PKGNAMEPREFIX}Jinja2=2.3:${PORTSDIR}/devel/py-Jinja2 \
+RUN_DEPENDS=
${PYTHON_PKGNAMEPREFIX}Jinja2=2.7:${PORTSDIR}/devel/py-Jinja2 \

${PYTHON_PKGNAMEPREFIX}docutils=0.7:${PORTSDIR}/textproc/py-docutils \

${PYTHON_PKGNAMEPREFIX}pygments=1.2:${PORTSDIR}/textproc/py-pygments


--
From: Benjamin Woods
woods...@gmail.com

  tex-kpathsea installed, but texlive-base didn't due to a failure to
  build the cmake dependency:
 [...]
  ===  Building for py27-sphinx-1.2.3
  /usr/local/bin/python2.7: No module named jinja2

 See how this is actually a failure to build the py-sphinx dependency.
 Does the port build if you try to build it individually?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: upgrading texlive broken due to cmake

2015-01-07 Thread Raphael Kubo da Costa
Will Parsons varro@nodomain.invalid writes:

 tex-kpathsea installed, but texlive-base didn't due to a failure to
 build the cmake dependency:
[...]
 ===  Building for py27-sphinx-1.2.3
 running build
 running build_py
 running egg_info
 writing requirements to Sphinx.egg-info/requires.txt
 writing Sphinx.egg-info/PKG-INFO
 writing top-level names to Sphinx.egg-info/top_level.txt
 writing dependency_links to Sphinx.egg-info/dependency_links.txt
 writing entry points to Sphinx.egg-info/entry_points.txt
 reading manifest file 'Sphinx.egg-info/SOURCES.txt'
 reading manifest template 'MANIFEST.in'
 no previously-included directories found matching 'doc/_build'
 writing manifest file 'Sphinx.egg-info/SOURCES.txt'
 cd /usr/ports/textproc/py-sphinx/work/Sphinx-1.2.3/build/lib 
 /usr/bin/env
 PYTHONPATH=/usr/ports/textproc/py-sphinx/work/Sphinx-1.2.3/build/lib:/usr/local/lib/python2.7/site-packages
 /usr/local/bin/python2.7 -m sphinx.pycode.pgen2.driver -c 'import
 load_grammar'
 /usr/local/bin/python2.7: No module named jinja2

See how this is actually a failure to build the py-sphinx dependency.
Does the port build if you try to build it individually?

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


upgrading texlive broken due to cmake

2015-01-07 Thread Will Parsons
In attempting to update texlive, I ran into a problem that is
addressed by UPDATING note 20141214.  Following the note I ran:

  # pkg delete -f tex-kpathsea texlive-base

and then attempted to install the new versions using portmaster.

tex-kpathsea installed, but texlive-base didn't due to a failure to
build the cmake dependency:

===

===  Patching for cmake-3.1.0
===  Applying FreeBSD patches for cmake-3.1.0
/bin/rm -f /usr/ports/devel/cmake/work/cmake-3.1.0/Help/manual/cmake-gui.1.rst
===   cmake-3.1.0 depends on executable: sphinx-build - not found
===Verifying install for sphinx-build in /usr/ports/textproc/py-sphinx
===  Building for py27-sphinx-1.2.3
running build
running build_py
running egg_info
writing requirements to Sphinx.egg-info/requires.txt
writing Sphinx.egg-info/PKG-INFO
writing top-level names to Sphinx.egg-info/top_level.txt
writing dependency_links to Sphinx.egg-info/dependency_links.txt
writing entry points to Sphinx.egg-info/entry_points.txt
reading manifest file 'Sphinx.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
no previously-included directories found matching 'doc/_build'
writing manifest file 'Sphinx.egg-info/SOURCES.txt'
cd /usr/ports/textproc/py-sphinx/work/Sphinx-1.2.3/build/lib   /usr/bin/env 
PYTHONPATH=/usr/ports/textproc/py-sphinx/work/Sphinx-1.2.3/build/lib:/usr/local/lib/python2.7/site-packages
  /usr/local/bin/python2.7 -m sphinx.pycode.pgen2.driver -c 'import 
load_grammar'
/usr/local/bin/python2.7: No module named jinja2
*** [post-build] Error code 1

Stop in /usr/ports/textproc/py-sphinx.
*** [build-depends] Error code 1

Stop in /usr/ports/devel/cmake.
*** [build] Error code 1

Stop in /usr/ports/devel/cmake.

=== make build failed for devel/cmake
=== Aborting update

=== Update for cmake-3.0.2 failed
=== Aborting update

=== Update for openjpeg15-1.5.2 failed
=== Aborting update

=== Update for tex-web2c-20140525 failed
=== Aborting update

===


I can't seem to find anything in UPDATING relevant.

-- 
Will

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


net/rabbitmq-c-devel and cmake hints needed (PR 186690)

2014-08-24 Thread Kurt Jaeger
Hi!

I'm trying to upgrade net/rabbitmq-c-devel and prepared a patch
for it. If someone understands more about cmake and the magic
behind it, I would appreciate it.

It builds fine on my host populated with approx. 2200 packages:

http://people.freebsd.org/~pi/misc/non-verbose-build.txt

Building it in poudriere, some bin/ stuff is not build (why?) and
the commands are displayed, so it's much more verbose
(why is it more verbose?).

http://people.freebsd.org/~pi/misc/verbose-build.txt

Thanks for any hint!

-- 
p...@opsec.eu+49 171 3101372 6 years to go !
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: net/rabbitmq-c-devel and cmake hints needed (PR 186690)

2014-08-24 Thread Antoine Brodin
On Sun, Aug 24, 2014 at 10:21 PM, Kurt Jaeger li...@opsec.eu wrote:
 Hi!

 I'm trying to upgrade net/rabbitmq-c-devel and prepared a patch
 for it. If someone understands more about cmake and the magic
 behind it, I would appreciate it.

 It builds fine on my host populated with approx. 2200 packages:

 http://people.freebsd.org/~pi/misc/non-verbose-build.txt

 Building it in poudriere, some bin/ stuff is not build (why?) and
 the commands are displayed, so it's much more verbose
 (why is it more verbose?).

 http://people.freebsd.org/~pi/misc/verbose-build.txt

 Thanks for any hint!


Hi,

From Uses/cmake.mk:

.if defined(BATCH) || defined(PACKAGE_BUILDING)
CMAKE_VERBOSE=  yes
CMAKE_NOCOLOR=  yes
.endif

For the tools,  it seems they need POPT and you didn't select the
option in poudriere.

Cheers,

Antoine
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: net/rabbitmq-c-devel and cmake hints needed (PR 186690)

2014-08-24 Thread Kurt Jaeger
Hi!

 From Uses/cmake.mk:
 
 .if defined(BATCH) || defined(PACKAGE_BUILDING)
 CMAKE_VERBOSE=  yes
 CMAKE_NOCOLOR=  yes
 .endif

Ah, thanks!

 For the tools,  it seems they need POPT and you didn't select the
 option in poudriere.

Thanks! That was indeed the problem!

-- 
p...@opsec.eu+49 171 3101372 6 years to go !
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


How to force cmake to omit default LINUX pathes on FreeBSD

2014-05-26 Thread Dariusz Niespodziany
Hi porters,
Does anyone know how to force cmake to look for executables in
/usr/local/bin first, not in /usr/bin?

*FIND_PROGRAM(FLEX_EXECUTABLE flex PATH /usr/local/bin DOC path to the
flex executable NO_DEFAULT_PATH)*

It works, but its not correct. Is there any more proper way?

FIND_PROGRAM uses which to get executable path. PATH variable is fetched,
but overriding $PATH is also not that proper.

Regards
niespodd
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Anyone having problems with CMake 2.8.12.1_3 and ftp/curl?

2014-03-09 Thread Raphael Kubo da Costa
I've received one report from a user on 8-STABLE saying my latest commit
to devel/cmake broke the build for him. Specifically, it fails like
this:

/usr/ports/devel/cmake/work/cmake-2.8.12.1/Utilities/cmcurl/multi.c:1708: 
error: expected declaration specifiers or '...' before numeric constant
/usr/ports/devel/cmake/work/cmake-2.8.12.1/Utilities/cmcurl/multi.c:1710: 
error: conflicting types for 'curl_multi_socket_action'
/usr/local/include/curl/multi.h:287: error: previous declaration of 
'curl_multi_socket_action' was here

I'm unable to reproduce it locally (-HEAD) or in a 8.4-i386 jail inside
Poudriere, even if I manually make ftp/curl a dependency in
devel/cmake's Makefile.

Has anyone else experienced the same issue?

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


Re: Anyone having problems with CMake 2.8.12.1_3 and ftp/curl?

2014-03-09 Thread Raphael Kubo da Costa
Raphael Kubo da Costa rak...@freebsd.org writes:

 Has anyone else experienced the same issue?

I've finally managed to reproduce the issue locally by installing
security/openssl.

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


Re: Anyone having problems with CMake 2.8.12.1_3 and ftp/curl?

2014-03-09 Thread Jim Trigg
On Sun, March 9, 2014 9:53 am, Raphael Kubo da Costa wrote:
 Raphael Kubo da Costa rak...@freebsd.org writes:

 Has anyone else experienced the same issue?

 I've finally managed to reproduce the issue locally by installing
 security/openssl.

A bit late, but FWIW I'm seeing it on 9.2-RELEASE as well.

Thanks,
Jim Trigg

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


Re: Anyone having problems with CMake 2.8.12.1_3 and ftp/curl?

2014-03-09 Thread Raphael Kubo da Costa
Raphael Kubo da Costa rak...@freebsd.org writes:

 Raphael Kubo da Costa rak...@freebsd.org writes:

 Has anyone else experienced the same issue?

 I've finally managed to reproduce the issue locally by installing
 security/openssl.

Thanks everyone, this should be fixed by r347674.

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



Re: [kde-freebsd] Error using CMake similar to error from earlier list post

2014-02-25 Thread David Naylor
Hi Joe,

Apologies for taking so long to get back to you.  Work got really, really 
busy. 

The underlying issue is that gcc pulls in the pthread headers by default while 
clang does not.  I believe clang is following the more correct approach.   

The files you attached are for traverso however I do not see it in the 
Port's Collection.  Are you building it directly from source?  

On Wednesday, 11 December 2013 21:02:27 Joe Nosay wrote:
  I'm attaching files.
  
  1. Undeclared identifier pthread_self:: Does this mean I need to add the
  pthread.h before every declaration of pthread_self?

No, you only need to add it once.  Normally there will be a header file.  
I'm guessing either to src/engine/AudioDeviceThread.cpp or to a header file 
included by src/engine/AudioDeviceThread.cpp

  2.  How do I declare an identifier?

I don't know what you are referring to, could you please elaborate?  

  3. CLang crashed somewhat at the beginning. Files are attached.

I see.  Can you please try with a newer version of clang/traverso.  If that 
does not fix the issue, then please report that upstream to the LLVM 
developers, this is well beyond my capabilities to fix.  

  The files will probably be too big for the mailing lists.
 
 Now, those errors which have references in section 2 of the man pages, do I
 replace as suggested with cpusetid_t. For others, do I introduce a patch
 similar to the pthread.h from the kopete patch?

Yes, patches similar to pthread.h should work.  Once you get the patches 
working please submit them upstream.  It makes our lives easier if those 
developers maintain the patches, instead of us.  

Regards

signature.asc
Description: This is a digitally signed message part.


Re: [kde-freebsd] Error using CMake similar to error from earlier list post

2013-12-11 Thread Joe Nosay
On Wed, Dec 11, 2013 at 6:12 PM, Joe Nosay superbisq...@gmail.com wrote:




 On Tue, Dec 10, 2013 at 8:42 PM, Joe Nosay superbisq...@gmail.com wrote:

 Thank you.



 On Tue, Dec 10, 2013 at 3:42 AM, David Naylor d...@freebsd.org wrote:

 Hi Joe,

 I'm listening!

 I've read through your thread on KDE-FreeBSD and Ports-FreeBSD however I
 am a
 bit fuzzy as to the issues.

 Are these specific to clang, FreeBSD = 10 or some other trigger?  How
 would I
 go about reproducing these errors?

 I'm happy to work with you to resolve these issues.

 Regards

 On Tuesday, 10 December 2013 04:25:58 Joe Nosay wrote:
  On Mon, Dec 9, 2013 at 11:18 PM, Joe Nosay superbisq...@gmail.com
 wrote:
   -- Forwarded message --
   From: Joe Nosay superbisq...@gmail.com
   Date: Sun, Dec 8, 2013 at 6:38 PM
   Subject: Re: Error using CMake similar to error from earlier list
 post
   To: kde-freebsd kde-free...@kde.org
  
   On Sat, Dec 7, 2013 at 3:45 PM, Joe Nosay superbisq...@gmail.com
 wrote:
   On Fri, Dec 6, 2013 at 7:50 PM, Joe Nosay superbisq...@gmail.com
 wrote:
   https://www.mail-archive.com/kde-freebsd@kde.org/msg15778.html
  
   Is there a similar fix for this?
  
   Thanks.
  
   Now would
   
  
   +Build fix for clang.
  
+
+  error: use of undeclared identifier 'pthread_mutex_lock'
+  error: use of undeclared identifier 'pthread_mutex_unlock'
+  error: use of undeclared identifier 'pthread_self'
+  error: use of undeclared identifier 'pthread_mutex_init'
+  error: use of undeclared identifier 'pthread_mutex_destroy'
+
+---
  
  kopete/protocols/jabber/googletalk/libjingle/talk/base/ssladapter.cc.or
ig
   2013-11-04 01:20:09.0 +0200
  

  
  kopete/protocols/jabber/googletalk/libjingle/talk/base/ssladapter.cc
  
   2013-11-04 01:20:20.0 +0200
  
+@@ -29,6 +29,7 @@
+
+ #ifdef POSIX
+ extern C {
++#include pthread.h
+ #include unistd.h
+ }
+ #endif
  
   Be the appropriate fix for
  
  
  
 /usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AudioDeviceTh
   read.cpp:58:30: error: use of undeclared identifier 'pthread_self'
   if (pthread_setschedparam (pthread_self(),
 SCHED_FIFO,
   param) != 0) {}
  
  ^
  
  
 /usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AudioDeviceTh
   read.cpp:131:30: error: use of undeclared identifier
 'pthread_self'
   if (pthread_setschedparam (pthread_self(),
 SCHED_FIFO,
   param) != 0) {
  
   I need to write a patch and then apply it to the script in question.
   1. Will I need to add the patch to each part that is listed?
  
  
  
  
  
  
  
  
   Since it is suggested to build an application natively - or at least
 try
   to - on FreeBSD before making a port, I am trying to do such.
  
   The errors seems to be the same CLang type as the others.
   Included is the file which was  modified according to the patch from
 the
   hyperlink stated earlier in this thread.
 
  Since this a CLang problem which has occurred and will occur in
 software
  with the same or similar type of instructions, it may be of use to
 make a
  patch for all qtX software and others with the same problem.
 
 
  Me Did I do the patch right?
  KDE FreeBSD Did you hear something?
  Ports FreeBSD Nope, not at all.
 
  GCC patchiness popping up here and there. I can see it and so can
 others.
 
  KDE FreeBSD What was that?
  Ports FreeBSD Nothing, nothing at all.
 
  These problems also show up on Debian and other systems transitioning
 to
  CLang for the compiler. Errors of the same type happen on software not
 in
  ports or natively part of kde3/4.
 
  KDE FreeBSD  There goes that noise again.
  Ports FreeBSD Just ignore it.



 As suggested somewhat by the patch in/for kopete. I tried adding the
 function to the file in question. What I did resulted in no change.

 -- Configuring done
 -- Generating done
 -- Build files have been written to:
 /usr/home/raspycat/traverso/work/traverso-0.49.2
 [  0%] Building CXX object
 src/engine/CMakeFiles/traversoaudiobackend.dir/AudioDeviceThread.o
 /usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AudioDeviceThread.cpp:65:30:
 error: use of undeclared identifier 'pthread_self'

 [I see this as a solution to that :
 http://stackoverflow.com/questions/11488361/lldb-error-use-of-undeclared-identifierbut
  how do I implement it as an applied patch ?]
 if (pthread_setschedparam (pthread_self(), SCHED_FIFO,
 param) != 0) {}

 [This was set in kopete and comes up in AudioDeviceThread.cpp as

 #ifdef POSIX
 extern C{
 #include /usr/include/pthread.h
 #include /usr/include/unistd.h
 }
 #endif]
^
 /usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AudioDeviceThread.cpp:138:30:
 error: use of undeclared identifier 'pthread_self'

 if (pthread_setschedparam

Re: Error using CMake similar to error from earlier list post

2013-12-10 Thread Joe Nosay
On Mon, Dec 9, 2013 at 11:18 PM, Joe Nosay superbisq...@gmail.com wrote:



 -- Forwarded message --
 From: Joe Nosay superbisq...@gmail.com
 Date: Sun, Dec 8, 2013 at 6:38 PM
 Subject: Re: Error using CMake similar to error from earlier list post
 To: kde-freebsd kde-free...@kde.org





 On Sat, Dec 7, 2013 at 3:45 PM, Joe Nosay superbisq...@gmail.com wrote:




 On Fri, Dec 6, 2013 at 7:50 PM, Joe Nosay superbisq...@gmail.com wrote:

 https://www.mail-archive.com/kde-freebsd@kde.org/msg15778.html

 Is there a similar fix for this?

 Thanks.




 Now would
 

 +Build fix for clang.
  +
  +  error: use of undeclared identifier 'pthread_mutex_lock'
  +  error: use of undeclared identifier 'pthread_mutex_unlock'
  +  error: use of undeclared identifier 'pthread_self'
  +  error: use of undeclared identifier 'pthread_mutex_init'
  +  error: use of undeclared identifier 'pthread_mutex_destroy'
  +
  +--- 
 kopete/protocols/jabber/googletalk/libjingle/talk/base/ssladapter.cc.orig
 2013-11-04 01:20:09.0 +0200
   kopete/protocols/jabber/googletalk/libjingle/talk/base/ssladapter.cc
 2013-11-04 01:20:20.0 +0200
  +@@ -29,6 +29,7 @@
  +
  + #ifdef POSIX
  + extern C {
  ++#include pthread.h
  + #include unistd.h
  + }
  + #endif


 Be the appropriate fix for


 /usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AudioDeviceThread.cpp:58:30:
  error: use of undeclared identifier 'pthread_self'
 if (pthread_setschedparam (pthread_self(), SCHED_FIFO, 
 param) != 0) {}
^
 /usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AudioDeviceThread.cpp:131:30:
  error: use of undeclared identifier 'pthread_self'
 if (pthread_setschedparam (pthread_self(), SCHED_FIFO, 
 param) != 0) {




 I need to write a patch and then apply it to the script in question.
 1. Will I need to add the patch to each part that is listed?








 Since it is suggested to build an application natively - or at least try
 to - on FreeBSD before making a port, I am trying to do such.

 The errors seems to be the same CLang type as the others.
 Included is the file which was  modified according to the patch from the
 hyperlink stated earlier in this thread.







Since this a CLang problem which has occurred and will occur in software
with the same or similar type of instructions, it may be of use to make a
patch for all qtX software and others with the same problem.


Me Did I do the patch right?
KDE FreeBSD Did you hear something?
Ports FreeBSD Nope, not at all.

GCC patchiness popping up here and there. I can see it and so can others.

KDE FreeBSD What was that?
Ports FreeBSD Nothing, nothing at all.

These problems also show up on Debian and other systems transitioning to
CLang for the compiler. Errors of the same type happen on software not in
ports or natively part of kde3/4.

KDE FreeBSD  There goes that noise again.
Ports FreeBSD Just ignore it.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: [kde-freebsd] Error using CMake similar to error from earlier list post

2013-12-10 Thread David Naylor
Hi Joe,

I'm listening!  

I've read through your thread on KDE-FreeBSD and Ports-FreeBSD however I am a 
bit fuzzy as to the issues.  

Are these specific to clang, FreeBSD = 10 or some other trigger?  How would I 
go about reproducing these errors?  

I'm happy to work with you to resolve these issues.  

Regards

On Tuesday, 10 December 2013 04:25:58 Joe Nosay wrote:
 On Mon, Dec 9, 2013 at 11:18 PM, Joe Nosay superbisq...@gmail.com wrote:
  -- Forwarded message --
  From: Joe Nosay superbisq...@gmail.com
  Date: Sun, Dec 8, 2013 at 6:38 PM
  Subject: Re: Error using CMake similar to error from earlier list post
  To: kde-freebsd kde-free...@kde.org
  
  On Sat, Dec 7, 2013 at 3:45 PM, Joe Nosay superbisq...@gmail.com wrote:
  On Fri, Dec 6, 2013 at 7:50 PM, Joe Nosay superbisq...@gmail.com wrote:
  https://www.mail-archive.com/kde-freebsd@kde.org/msg15778.html
  
  Is there a similar fix for this?
  
  Thanks.
  
  Now would
  
  
  +Build fix for clang.
  
   +
   +  error: use of undeclared identifier 'pthread_mutex_lock'
   +  error: use of undeclared identifier 'pthread_mutex_unlock'
   +  error: use of undeclared identifier 'pthread_self'
   +  error: use of undeclared identifier 'pthread_mutex_init'
   +  error: use of undeclared identifier 'pthread_mutex_destroy'
   +
   +---
   kopete/protocols/jabber/googletalk/libjingle/talk/base/ssladapter.cc.or
   ig 
  2013-11-04 01:20:09.0 +0200
  
   
   kopete/protocols/jabber/googletalk/libjingle/talk/base/ssladapter.cc
  
  2013-11-04 01:20:20.0 +0200
  
   +@@ -29,6 +29,7 @@
   +
   + #ifdef POSIX
   + extern C {
   ++#include pthread.h
   + #include unistd.h
   + }
   + #endif
  
  Be the appropriate fix for
  
  
  /usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AudioDeviceTh
  read.cpp:58:30: error: use of undeclared identifier 'pthread_self' 
  if (pthread_setschedparam (pthread_self(), SCHED_FIFO,
  param) != 0) {}
  
 ^
  
  /usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AudioDeviceTh
  read.cpp:131:30: error: use of undeclared identifier 'pthread_self' 
  if (pthread_setschedparam (pthread_self(), SCHED_FIFO,
  param) != 0) {
  
  I need to write a patch and then apply it to the script in question.
  1. Will I need to add the patch to each part that is listed?
  
  
  
  
  
  
  
  
  Since it is suggested to build an application natively - or at least try
  to - on FreeBSD before making a port, I am trying to do such.
  
  The errors seems to be the same CLang type as the others.
  Included is the file which was  modified according to the patch from the
  hyperlink stated earlier in this thread.
 
 Since this a CLang problem which has occurred and will occur in software
 with the same or similar type of instructions, it may be of use to make a
 patch for all qtX software and others with the same problem.
 
 
 Me Did I do the patch right?
 KDE FreeBSD Did you hear something?
 Ports FreeBSD Nope, not at all.
 
 GCC patchiness popping up here and there. I can see it and so can others.
 
 KDE FreeBSD What was that?
 Ports FreeBSD Nothing, nothing at all.
 
 These problems also show up on Debian and other systems transitioning to
 CLang for the compiler. Errors of the same type happen on software not in
 ports or natively part of kde3/4.
 
 KDE FreeBSD  There goes that noise again.
 Ports FreeBSD Just ignore it.

signature.asc
Description: This is a digitally signed message part.


Re: [kde-freebsd] Error using CMake similar to error from earlier list post

2013-12-10 Thread Joe Nosay
Thank you.


On Tue, Dec 10, 2013 at 3:42 AM, David Naylor d...@freebsd.org wrote:

 Hi Joe,

 I'm listening!

 I've read through your thread on KDE-FreeBSD and Ports-FreeBSD however I
 am a
 bit fuzzy as to the issues.

 Are these specific to clang, FreeBSD = 10 or some other trigger?  How
 would I
 go about reproducing these errors?

 I'm happy to work with you to resolve these issues.

 Regards

 On Tuesday, 10 December 2013 04:25:58 Joe Nosay wrote:
  On Mon, Dec 9, 2013 at 11:18 PM, Joe Nosay superbisq...@gmail.com
 wrote:
   -- Forwarded message --
   From: Joe Nosay superbisq...@gmail.com
   Date: Sun, Dec 8, 2013 at 6:38 PM
   Subject: Re: Error using CMake similar to error from earlier list post
   To: kde-freebsd kde-free...@kde.org
  
   On Sat, Dec 7, 2013 at 3:45 PM, Joe Nosay superbisq...@gmail.com
 wrote:
   On Fri, Dec 6, 2013 at 7:50 PM, Joe Nosay superbisq...@gmail.com
 wrote:
   https://www.mail-archive.com/kde-freebsd@kde.org/msg15778.html
  
   Is there a similar fix for this?
  
   Thanks.
  
   Now would
   
  
   +Build fix for clang.
  
+
+  error: use of undeclared identifier 'pthread_mutex_lock'
+  error: use of undeclared identifier 'pthread_mutex_unlock'
+  error: use of undeclared identifier 'pthread_self'
+  error: use of undeclared identifier 'pthread_mutex_init'
+  error: use of undeclared identifier 'pthread_mutex_destroy'
+
+---
  
  kopete/protocols/jabber/googletalk/libjingle/talk/base/ssladapter.cc.or
ig
   2013-11-04 01:20:09.0 +0200
  

kopete/protocols/jabber/googletalk/libjingle/talk/base/ssladapter.cc
  
   2013-11-04 01:20:20.0 +0200
  
+@@ -29,6 +29,7 @@
+
+ #ifdef POSIX
+ extern C {
++#include pthread.h
+ #include unistd.h
+ }
+ #endif
  
   Be the appropriate fix for
  
  
  
 /usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AudioDeviceTh
   read.cpp:58:30: error: use of undeclared identifier 'pthread_self'
   if (pthread_setschedparam (pthread_self(), SCHED_FIFO,
   param) != 0) {}
  
  ^
  
  
 /usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AudioDeviceTh
   read.cpp:131:30: error: use of undeclared identifier 'pthread_self'
   if (pthread_setschedparam (pthread_self(), SCHED_FIFO,
   param) != 0) {
  
   I need to write a patch and then apply it to the script in question.
   1. Will I need to add the patch to each part that is listed?
  
  
  
  
  
  
  
  
   Since it is suggested to build an application natively - or at least
 try
   to - on FreeBSD before making a port, I am trying to do such.
  
   The errors seems to be the same CLang type as the others.
   Included is the file which was  modified according to the patch from
 the
   hyperlink stated earlier in this thread.
 
  Since this a CLang problem which has occurred and will occur in software
  with the same or similar type of instructions, it may be of use to make a
  patch for all qtX software and others with the same problem.
 
 
  Me Did I do the patch right?
  KDE FreeBSD Did you hear something?
  Ports FreeBSD Nope, not at all.
 
  GCC patchiness popping up here and there. I can see it and so can others.
 
  KDE FreeBSD What was that?
  Ports FreeBSD Nothing, nothing at all.
 
  These problems also show up on Debian and other systems transitioning to
  CLang for the compiler. Errors of the same type happen on software not in
  ports or natively part of kde3/4.
 
  KDE FreeBSD  There goes that noise again.
  Ports FreeBSD Just ignore it.



As suggested somewhat by the patch in/for kopete. I tried adding the
function to the file in question. What I did resulted in no change.

-- Configuring done
-- Generating done
-- Build files have been written to:
/usr/home/raspycat/traverso/work/traverso-0.49.2
[  0%] Building CXX object
src/engine/CMakeFiles/traversoaudiobackend.dir/AudioDeviceThread.o
/usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AudioDeviceThread.cpp:65:30:
error: use of undeclared identifier 'pthread_self'

[I see this as a solution to that :
http://stackoverflow.com/questions/11488361/lldb-error-use-of-undeclared-identifierbut
how do I implement it as an applied patch ?]
if (pthread_setschedparam (pthread_self(), SCHED_FIFO,
param) != 0) {}

[This was set in kopete and comes up in AudioDeviceThread.cpp as

#ifdef POSIX
extern C{
#include /usr/include/pthread.h
#include /usr/include/unistd.h
}
#endif]
   ^
/usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AudioDeviceThread.cpp:138:30:
error: use of undeclared identifier 'pthread_self'
if (pthread_setschedparam (pthread_self(), SCHED_FIFO,
param) != 0) {



 http://clang.debian.net/logs/2011-09-11/traverso_0.49.2-4_lsid64c.buildlog

The log shows that the CLang errors also occurs on other operating

Fwd: Error using CMake similar to error from earlier list post

2013-12-09 Thread Joe Nosay
-- Forwarded message --
From: Joe Nosay superbisq...@gmail.com
Date: Sun, Dec 8, 2013 at 6:38 PM
Subject: Re: Error using CMake similar to error from earlier list post
To: kde-freebsd kde-free...@kde.org





On Sat, Dec 7, 2013 at 3:45 PM, Joe Nosay superbisq...@gmail.com wrote:




 On Fri, Dec 6, 2013 at 7:50 PM, Joe Nosay superbisq...@gmail.com wrote:

 https://www.mail-archive.com/kde-freebsd@kde.org/msg15778.html

 Is there a similar fix for this?

 Thanks.




 Now would
 

 +Build fix for clang.
  +
  +  error: use of undeclared identifier 'pthread_mutex_lock'
  +  error: use of undeclared identifier 'pthread_mutex_unlock'
  +  error: use of undeclared identifier 'pthread_self'
  +  error: use of undeclared identifier 'pthread_mutex_init'
  +  error: use of undeclared identifier 'pthread_mutex_destroy'
  +
  +--- 
 kopete/protocols/jabber/googletalk/libjingle/talk/base/ssladapter.cc.orig
 2013-11-04 01:20:09.0 +0200
   kopete/protocols/jabber/googletalk/libjingle/talk/base/ssladapter.cc
 2013-11-04 01:20:20.0 +0200
  +@@ -29,6 +29,7 @@
  +
  + #ifdef POSIX
  + extern C {
  ++#include pthread.h
  + #include unistd.h
  + }
  + #endif


 Be the appropriate fix for


 /usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AudioDeviceThread.cpp:58:30:
  error: use of undeclared identifier 'pthread_self'
 if (pthread_setschedparam (pthread_self(), SCHED_FIFO, 
 param) != 0) {}
^
 /usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AudioDeviceThread.cpp:131:30:
  error: use of undeclared identifier 'pthread_self'
 if (pthread_setschedparam (pthread_self(), SCHED_FIFO, 
 param) != 0) {




I need to write a patch and then apply it to the script in question.
1. Will I need to add the patch to each part that is listed?








Since it is suggested to build an application natively - or at least try to
- on FreeBSD before making a port, I am trying to do such.

The errors seems to be the same CLang type as the others.
Included is the file which was  modified according to the patch from the
hyperlink stated earlier in this thread.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: MariaDB 5.5.53a (Was: CMake, libexecinfo, ${LOCALBASE}/lib and ldconfig)

2013-09-27 Thread Alexandr Kovalenko
On Thu, Sep 26, 2013 at 3:54 PM, Michael Gmelin free...@grem.de wrote:
 On Thu, 26 Sep 2013 15:28:54 +0100
 Alexandr Kovalenko ne...@nevermind.kiev.ua wrote:

 On Thu, Sep 26, 2013 at 3:05 PM, Michael Gmelin free...@grem.de
 wrote:

  Since you're working on 5.5.33a it would be great if you could
  incorporate the patches I just submitted to allow building mariadb
  using clang's libc++
  http://www.freebsd.org/cgi/query-pr.cgi?pr=182408 .

 ports/182287 should be closed [adding flo@ : ], as I will submit
 maintainer update soon and also this PR does not actually enable
 TOKUDB (which is what I'm fighting now, but probably will give up for
 now and submit update without it to work on TOKUDB later).

 2. Would you be so kind to send me patches against current (5.5.33a)
 source to help me a bit? :)

 I verified my patches against 5.5.33a from 2013-09-20:

 patch-sql_item_subselect.cc: applies ok
 patch-storage_pbxt_src_strutil_xt.cc: pbxt has been removed
 patch-storage_pbxt_src_index_xt.cc: pbxt has been removed
 patch-storage_pbxt_src_util_xt.cc: pbxt has been removed
 patch-storage_federated_ha_federated.cc: already upstream
 patch-sql_sql_trigger.cc: ok
 patch-sql_sql_view.cc: ok

 This means that only three patches will be required. Just untar the
 attached tarball in the ports files directory:

 cd /usr/ports/databases/mariadb55-server/files
 tar -xzf /path/to/patches.tgz

 There might be more challenges new to this version of MariaDB, so I'm
 more than happy to test the port once you're ready.

Thanks, your patches are incorporated into
http://www.freebsd.org/cgi/query-pr.cgi?pr=182426 :)

Please feel free to test this update and report any problems you may
encounter :)

-- 
Alexandr.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


cmake missing although its defined in USES=

2013-09-27 Thread mike

Hi,
kicad-devel fails to compile on the cluster:
(Full log in 
http://beefy2.isc.freebsd.org/bulk/latest-per-pkg/kicad-devel/r4313_3/head-amd64-default.log 
)


...
===phase: configure  
===  Configuring for kicad-devel-r4313_3
===  Performing in-source build
/bin/mkdir -p /wrkdirs/usr/ports/cad/kicad-devel/work/kicad-r4313
env: /usr/local/bin/cmake: No such file or directory
*** Error code 127

Stop.
make: stopped in /usr/ports/cad/kicad-devel
===  Cleaning for kicad-devel-r4313_3
build of /usr/ports/cad/kicad-devel ended at Thu Sep 26 08:23:31 UTC 2013
build time: 00:01:33
...

But it has defined in the Makefile:
...
USES=   cmake gettext
...

How can this happen?

CU
---
Michael Reifenberger
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: MariaDB 5.5.53a (Was: CMake, libexecinfo, ${LOCALBASE}/lib and ldconfig)

2013-09-27 Thread Michael Gmelin
On Fri, 27 Sep 2013 10:31:22 +0100
Alexandr Kovalenko ne...@nevermind.kiev.ua wrote:

 On Thu, Sep 26, 2013 at 3:54 PM, Michael Gmelin free...@grem.de
 wrote:
  On Thu, 26 Sep 2013 15:28:54 +0100
  Alexandr Kovalenko ne...@nevermind.kiev.ua wrote:
 
  On Thu, Sep 26, 2013 at 3:05 PM, Michael Gmelin free...@grem.de
  wrote:
 
   Since you're working on 5.5.33a it would be great if you could
   incorporate the patches I just submitted to allow building
   mariadb using clang's libc++
   http://www.freebsd.org/cgi/query-pr.cgi?pr=182408 .
 
  ports/182287 should be closed [adding flo@ : ], as I will submit
  maintainer update soon and also this PR does not actually enable
  TOKUDB (which is what I'm fighting now, but probably will give up
  for now and submit update without it to work on TOKUDB later).
 
  2. Would you be so kind to send me patches against current
  (5.5.33a) source to help me a bit? :)
 
  I verified my patches against 5.5.33a from 2013-09-20:
 
  patch-sql_item_subselect.cc: applies ok
  patch-storage_pbxt_src_strutil_xt.cc: pbxt has been removed
  patch-storage_pbxt_src_index_xt.cc: pbxt has been removed
  patch-storage_pbxt_src_util_xt.cc: pbxt has been removed
  patch-storage_federated_ha_federated.cc: already upstream
  patch-sql_sql_trigger.cc: ok
  patch-sql_sql_view.cc: ok
 
  This means that only three patches will be required. Just untar the
  attached tarball in the ports files directory:
 
  cd /usr/ports/databases/mariadb55-server/files
  tar -xzf /path/to/patches.tgz
 
  There might be more challenges new to this version of MariaDB, so
  I'm more than happy to test the port once you're ready.
 
 Thanks, your patches are incorporated into
 http://www.freebsd.org/cgi/query-pr.cgi?pr=182426 :)
 
 Please feel free to test this update and report any problems you may
 encounter :)
 

Hi Alexandr,

I tested the port and everything builds fine, no leftovers etc. I'll
let you know if I hit any runtime issues, but so far things look good.
IMHO this is ready for production.

Thanks for your work,
Michael

-- 
Michael Gmelin
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


CMake, libexecinfo, ${LOCALBASE}/lib and ldconfig

2013-09-26 Thread Alexandr Kovalenko
Hello,

I'm working on 5.5.33a MariaDB port now and got trouble making cmake
to find libexecinfo (stub for linuxish backtrace() function).

I'm desperate now in trying to fight this thing:

Determining if the function backtrace exists failed with the following output:
Change Dir: 
/usr/ports/databases/mariadb55-server/work/mariadb-5.5.33a/CMakeFiles/CMakeTmp

Run Build Command:/usr/local/bin/gmake cmTryCompileExec343489733/fast
/usr/local/bin/gmake -f
CMakeFiles/cmTryCompileExec343489733.dir/build.make
CMakeFiles/cmTryCompileExec343489733.dir/build
gmake[1]: Entering directory
`/usr/ports/databases/mariadb55-server/work/mariadb-5.5.33a/CMakeFiles/CMakeTmp'
/usr/local/bin/cmake -E cmake_progress_report
/usr/ports/databases/mariadb55-server/work/mariadb-5.5.33a/CMakeFiles/CMakeTmp/CMakeFiles
1
Building C object
CMakeFiles/cmTryCompileExec343489733.dir/CheckFunctionExists.c.o
/usr/bin/clang  -D_LARGEFILE_SOURCE -D_LARGE_FILES
-D_FILE_OFFSET_BITS=64 -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -O2 -pipe -fno-strict-aliasing
-DCHECK_FUNCTION_EXISTS=backtrace   -o
CMakeFiles/cmTryCompileExec343489733.dir/CheckFunctionExists.c.o   -c
/usr/local/share/cmake/Modules/CheckFunctionExists.c
Linking C executable cmTryCompileExec343489733
/usr/local/bin/cmake -E cmake_link_script
CMakeFiles/cmTryCompileExec343489733.dir/link.txt --verbose=1
/usr/bin/clang   -O2 -pipe -fno-strict-aliasing
-DCHECK_FUNCTION_EXISTS=backtrace
CMakeFiles/cmTryCompileExec343489733.dir/CheckFunctionExists.c.o  -o
cmTryCompileExec343489733  -lexecinfo
/usr/bin/ld: cannot find -lexecinfo
clang: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[1]: Leaving directory
`/usr/ports/databases/mariadb55-server/work/mariadb-5.5.33a/CMakeFiles/CMakeTmp'
gmake[1]: *** [cmTryCompileExec343489733] Error 1
gmake: *** [cmTryCompileExec343489733/fast] Error 2


root@vbox:~ # ldconfig -r | grep execinfo
141:-lexecinfo.1 = /usr/local/lib/libexecinfo.so.1

Could anyone, please, explain me, why clang can't see libexecinfo
during link phase and how to fix it?

Thanks in advance!

-- 
Alexandr
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: CMake, libexecinfo, ${LOCALBASE}/lib and ldconfig

2013-09-26 Thread Michael Gmelin
On Thu, 26 Sep 2013 14:00:32 +0100
Alexandr Kovalenko ne...@nevermind.kiev.ua wrote:

 Hello,
 
 I'm working on 5.5.33a MariaDB port now and got trouble making cmake
 to find libexecinfo (stub for linuxish backtrace() function).
 
 I'm desperate now in trying to fight this thing:
 
 Determining if the function backtrace exists failed with the
 following output: Change
 Dir: 
 /usr/ports/databases/mariadb55-server/work/mariadb-5.5.33a/CMakeFiles/CMakeTmp
 
 Run Build Command:/usr/local/bin/gmake
 cmTryCompileExec343489733/fast /usr/local/bin/gmake -f
 CMakeFiles/cmTryCompileExec343489733.dir/build.make
 CMakeFiles/cmTryCompileExec343489733.dir/build
 gmake[1]: Entering directory
 `/usr/ports/databases/mariadb55-server/work/mariadb-5.5.33a/CMakeFiles/CMakeTmp'
 /usr/local/bin/cmake -E cmake_progress_report
 /usr/ports/databases/mariadb55-server/work/mariadb-5.5.33a/CMakeFiles/CMakeTmp/CMakeFiles
 1
 Building C object
 CMakeFiles/cmTryCompileExec343489733.dir/CheckFunctionExists.c.o
 /usr/bin/clang  -D_LARGEFILE_SOURCE -D_LARGE_FILES
 -D_FILE_OFFSET_BITS=64 -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
 -D__STDC_FORMAT_MACROS -O2 -pipe -fno-strict-aliasing
 -DCHECK_FUNCTION_EXISTS=backtrace   -o
 CMakeFiles/cmTryCompileExec343489733.dir/CheckFunctionExists.c.o   -c
 /usr/local/share/cmake/Modules/CheckFunctionExists.c
 Linking C executable cmTryCompileExec343489733
 /usr/local/bin/cmake -E cmake_link_script
 CMakeFiles/cmTryCompileExec343489733.dir/link.txt --verbose=1
 /usr/bin/clang   -O2 -pipe -fno-strict-aliasing
 -DCHECK_FUNCTION_EXISTS=backtrace
 CMakeFiles/cmTryCompileExec343489733.dir/CheckFunctionExists.c.o  -o
 cmTryCompileExec343489733  -lexecinfo
 /usr/bin/ld: cannot find -lexecinfo
 clang: error: linker command failed with exit code 1 (use -v to see
 invocation) gmake[1]: Leaving directory
 `/usr/ports/databases/mariadb55-server/work/mariadb-5.5.33a/CMakeFiles/CMakeTmp'
 gmake[1]: *** [cmTryCompileExec343489733] Error 1
 gmake: *** [cmTryCompileExec343489733/fast] Error 2
 
 
 root@vbox:~ # ldconfig -r | grep execinfo
 141:-lexecinfo.1 = /usr/local/lib/libexecinfo.so.1
 
 Could anyone, please, explain me, why clang can't see libexecinfo
 during link phase and how to fix it?
 
 Thanks in advance!
 

Hi Alexandr,

Since you're working on 5.5.33a it would be great if you could
incorporate the patches I just submitted to allow building mariadb
using clang's libc++ http://www.freebsd.org/cgi/query-pr.cgi?pr=182408 .

As for your problem, there's been an ldconfig bug in the ports tree a
few days ago, maybe updating it will fix this for you (this is just a
wild speculation, I didn't really check if it is related). Feel free
to send me a tarball of the port skeleton off-list in case you're stuck.

Cheers,
Michael


-- 
Michael Gmelin
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: CMake, libexecinfo, ${LOCALBASE}/lib and ldconfig

2013-09-26 Thread Alexandr Kovalenko
On Thu, Sep 26, 2013 at 3:05 PM, Michael Gmelin free...@grem.de wrote:

 Since you're working on 5.5.33a it would be great if you could
 incorporate the patches I just submitted to allow building mariadb
 using clang's libc++ http://www.freebsd.org/cgi/query-pr.cgi?pr=182408 .

ports/182287 should be closed [adding flo@ : ], as I will submit
maintainer update soon and also this PR does not actually enable
TOKUDB (which is what I'm fighting now, but probably will give up for
now and submit update without it to work on TOKUDB later).

I'm more than happy to apply your patches. I have few questions:

1. Will those patches affect build on stdlibc++ in any way?
2. Would you be so kind to send me patches against current (5.5.33a)
source to help me a bit? :)

Thanks in advance!

 As for your problem, there's been an ldconfig bug in the ports tree a
 few days ago, maybe updating it will fix this for you (this is just a
 wild speculation, I didn't really check if it is related). Feel free
 to send me a tarball of the port skeleton off-list in case you're stuck.


-- 
Alexandr.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: CMake, libexecinfo, ${LOCALBASE}/lib and ldconfig

2013-09-26 Thread Michael Gmelin
On Thu, 26 Sep 2013 15:28:54 +0100
Alexandr Kovalenko ne...@nevermind.kiev.ua wrote:

 On Thu, Sep 26, 2013 at 3:05 PM, Michael Gmelin free...@grem.de
 wrote:
 
  Since you're working on 5.5.33a it would be great if you could
  incorporate the patches I just submitted to allow building mariadb
  using clang's libc++
  http://www.freebsd.org/cgi/query-pr.cgi?pr=182408 .
 
 ports/182287 should be closed [adding flo@ : ], as I will submit
 maintainer update soon and also this PR does not actually enable
 TOKUDB (which is what I'm fighting now, but probably will give up for
 now and submit update without it to work on TOKUDB later).
 
 I'm more than happy to apply your patches. I have few questions:
 
 1. Will those patches affect build on stdlibc++ in any way?

Nope, those are all backwards compatible and standard compliant changes.
I just double checked by building mariadb55 using gcc4.2.1 and stdlibc++
on 9.1-RELEASE.

 2. Would you be so kind to send me patches against current (5.5.33a)
 source to help me a bit? :)

I verified my patches against 5.5.33a from 2013-09-20:

patch-sql_item_subselect.cc: applies ok
patch-storage_pbxt_src_strutil_xt.cc: pbxt has been removed
patch-storage_pbxt_src_index_xt.cc: pbxt has been removed
patch-storage_pbxt_src_util_xt.cc: pbxt has been removed
patch-storage_federated_ha_federated.cc: already upstream
patch-sql_sql_trigger.cc: ok
patch-sql_sql_view.cc: ok

This means that only three patches will be required. Just untar the
attached tarball in the ports files directory:

cd /usr/ports/databases/mariadb55-server/files
tar -xzf /path/to/patches.tgz

There might be more challenges new to this version of MariaDB, so I'm
more than happy to test the port once you're ready.

Cheers,
Michael

 
 Thanks in advance!





-- 
Michael Gmelin
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Anytime color highlighted mode for CMAKE

2013-07-06 Thread RyōTa SimaMoto
# Anytime color highlighted mode for CMAKE

Hi,

On usual terminal including ttyvN, if you add USE_GMAKE=yes on Mk/Uses/cmake.mk,
'cmake' gave colored output.  Since USES+=gmake is recommended, what way is
provided for custom setting to enable 'gmake' on USES macro when other certain
function is invoked?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


databases/akonadi: CURRENT: can not update: CMake Error at /usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:97 (MESSAGE):, Could NOT find Qt4 (missing: QT_MOC_EXECUTABLE QT_RCC_EXECU

2013-02-02 Thread O. Hartmann
Updating databases/akonadi ends up in the follwoig error ad this blocks
updating a bunch of other important ports:

===  Configuring for akonadi-1.7.2_4
/bin/mkdir -p /usr/ports/databases/akonadi/work/akonadi-1.7.2/build
-- Using default db backend QMYSQL
CMake Error at
/usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:97
(MESSAGE):
  Could NOT find Qt4 (missing: QT_MOC_EXECUTABLE QT_RCC_EXECUTABLE
  QT_UIC_EXECUTABLE QT_INCLUDE_DIR QT_LIBRARY_DIR QT_QTCORE_LIBRARY)
  (Required is at least version 4.6.0)
Call Stack (most recent call first):
  /usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:288
(_FPHSA_FAILURE_MESSAGE)
  /usr/local/share/cmake/Modules/FindQt4.cmake:1186
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:117 (find_package)


-- Configuring incomplete, errors occurred!
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_C_COMPILER= cc
CMAKE_CXX_COMPILER= c++

-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

CMAKE_CXX_FLAGS
CMAKE_CXX_FLAGS_DEBUG
CMAKE_CXX_FLAGS_RELEASE
CMAKE_C_FLAGS
CMAKE_C_FLAGS_DEBUG
CMAKE_C_FLAGS_RELEASE
CMAKE_EXE_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS
CMAKE_REQUIRED_INCLUDES
CMAKE_SHARED_LINKER_FLAGS
INSTALL_QSQLITE_IN_QT_PREFIX
THREADS_HAVE_PTHREAD_ARG


-- Build files have been written to:
/usr/ports/databases/akonadi/work/akonadi-1.7.2/build
*** [do-configure] Error code 1

Stop in /usr/ports/databases/akonadi.
*** [install] Error code 1

Stop in /usr/ports/databases/akonadi.
*** [reinstall] Error code 1



signature.asc
Description: OpenPGP digital signature


Re: Problem building cmake

2012-05-18 Thread Conrad J. Sabatier
On Tue, May 15, 2012 at 10:11:25PM -0500, Conrad J. Sabatier wrote:
 On Tue, 15 May 2012 23:32:56 -0300
 Raphael Kubo da Costa rak...@freebsd.org wrote:
 
  Conrad J. Sabatier conr...@cox.net writes:
  
   When did 2.8.8 make it into the ports repo?
  
  On May 3rd when I committed it :-) For reference,
  http://www.freshports.org/devel/cmake.
 
 How odd.  I csup my local CVS repo regularly, and it hasn't turned up
 yet.  May be time to switch mirrors.

Well, another mystery solved.

Just discovered that the script I've been running out of cron to update 
my local CVS repository had a typo in it, and csup wasn't being run at 
all.  Not sure when that occurred exactly, but anyway...

No wonder I hadn't seen any new versions of ports in a while.  Doh!  :-)

-- 
Conrad J. Sabatier
conr...@cox.net
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: Problem building cmake

2012-05-17 Thread Raphael Kubo da Costa
Francisco Souza f...@souza.cc writes:

 I managed to build cmake after deinstalling curl... Then I reinstalled
 curl. odd...

 Does cmake embbed libcurl?

Yes, it does. I still find your build problem weird, as I have curl
installed here and have never had any problems building cmake.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: Problem building cmake

2012-05-16 Thread Francisco Souza
I managed to build cmake after deinstalling curl... Then I reinstalled
curl. odd...

Does cmake embbed libcurl?

On Wed, May 16, 2012 at 12:11 AM, Conrad J. Sabatier conr...@cox.netwrote:

 On Tue, 15 May 2012 23:32:56 -0300
 Raphael Kubo da Costa rak...@freebsd.org wrote:

  Conrad J. Sabatier conr...@cox.net writes:
 
   When did 2.8.8 make it into the ports repo?
 
  On May 3rd when I committed it :-) For reference,
  http://www.freshports.org/devel/cmake.

 How odd.  I csup my local CVS repo regularly, and it hasn't turned up
 yet.  May be time to switch mirrors.

 --
 Conrad J. Sabatier
 conr...@cox.net
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org




-- 
~f
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Problem building cmake

2012-05-15 Thread Francisco Souza
Hi there,
I can't install cmake:

# make install clean
===  Building for cmake-2.8.8
[  2%] Built target cmIML_test
[  6%] Built target cmsys
[  7%] Built target cmsys_c
[ 10%] Built target cmzlib
[ 10%] Built target cmcompress
[ 12%] Built target cmbzip2
[ 13%] Built target cmexpat
[ 13%] Built target foo
[ 22%] Built target cmForm
[ 22%] Built target cmsysTestDynload
[ 25%] Built target cmsysTestsCxx
[ 25%] Built target cmsysTestProcess
[ 26%] Built target cmsysTestSharedForward
[ 26%] Built target cmsysTestsC
[ 26%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/multi.c.o
[ 45%] Built target cmlibarchive
[ 46%] Building C object
Utilities/cmcurl/CMakeFiles/cmcurl.dir/parsedate.c.o
[ 46%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/progress.c.o
/usr/ports/devel/cmake/work/cmake-2.8.8/Utilities/cmcurl/multi.c:1708:
error: expected declaration specifiers or '...' before numeric constant
/usr/ports/devel/cmake/work/cmake-2.8.8/Utilities/cmcurl/multi.c:1710:
error: conflicting types for 'curl_multi_socket_action'
/usr/local/include/curl/multi.h:258: error: previous declaration of
'curl_multi_socket_action' was here
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 1

Stop in /usr/ports/devel/cmake.

I'm using FreeBSD 8.3.

Does anyone know this error?

-- 
~f
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: Problem building cmake

2012-05-15 Thread Raphael Kubo da Costa
Francisco Souza f...@souza.cc writes:

 [ 26%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/multi.c.o
 [ 45%] Built target cmlibarchive
 [ 46%] Building C object
 Utilities/cmcurl/CMakeFiles/cmcurl.dir/parsedate.c.o
 [ 46%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/progress.c.o
 /usr/ports/devel/cmake/work/cmake-2.8.8/Utilities/cmcurl/multi.c:1708:
 error: expected declaration specifiers or '...' before numeric constant
 /usr/ports/devel/cmake/work/cmake-2.8.8/Utilities/cmcurl/multi.c:1710:
 error: conflicting types for 'curl_multi_socket_action'
 /usr/local/include/curl/multi.h:258: error: previous declaration of
 'curl_multi_socket_action' was here

Can you cd to $WRKSRC and run `make -j1 V=1' and post the output of the
failing compiler call?

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


  1   2   >