Re: [CFT] TPM(Trusted Platform Modules) replated ports

2013-12-05 Thread Hiroki Sato
Andrey Fesenko f0and...@gmail.com wrote
  in CA+K5SrOCqSs5f8iDh+d+wAp4kX-U2D6us=OPyj=vxryegyr...@mail.gmail.com:

f0 On Thu, Dec 5, 2013 at 5:10 AM, hiren panchasara
f0 hiren.panchas...@gmail.com wrote:
f0  On Wed, Dec 4, 2013 at 5:01 PM, Andrey Fesenko f0and...@gmail.com wrote:
f0 
f0  security/trousers - need add user in comand line and remove path var
f0  directory pkg-plist
f0  hrs@ just fixed this port a few mins back.
f0 
f0 Yes, install not error :)
f0
f0  security/opencryptoki - checking for csulincl.h... no
f0  configure: error: tpm token build requested but TSS development files 
not found
f0  ===  Script configure failed unexpectedly.
f0 
f0  Try sending this report on ports@ ?
f0 
f0  cheers,
f0  Hiren
f0
f0 No, make cc this message.
f0 ports revision 335651

 Can you try r335654?  security/trousers has to be updated because of
 iconv library conflict.

-- Hiroki


pgpyVIbmfFcEA.pgp
Description: PGP signature


Re: [CFT] TPM(Trusted Platform Modules) replated ports

2013-12-05 Thread Andrey Fesenko
On Thu, Dec 5, 2013 at 12:06 PM, Hiroki Sato h...@freebsd.org wrote:
 Andrey Fesenko f0and...@gmail.com wrote
   in CA+K5SrOCqSs5f8iDh+d+wAp4kX-U2D6us=OPyj=vxryegyr...@mail.gmail.com:

 f0 On Thu, Dec 5, 2013 at 5:10 AM, hiren panchasara
 f0 hiren.panchas...@gmail.com wrote:
 f0  On Wed, Dec 4, 2013 at 5:01 PM, Andrey Fesenko f0and...@gmail.com 
 wrote:
 f0 
 f0  security/trousers - need add user in comand line and remove path var
 f0  directory pkg-plist
 f0  hrs@ just fixed this port a few mins back.
 f0 
 f0 Yes, install not error :)
 f0
 f0  security/opencryptoki - checking for csulincl.h... no
 f0  configure: error: tpm token build requested but TSS development files 
 not found
 f0  ===  Script configure failed unexpectedly.
 f0 
 f0  Try sending this report on ports@ ?
 f0 
 f0  cheers,
 f0  Hiren
 f0
 f0 No, make cc this message.
 f0 ports revision 335651

  Can you try r335654?  security/trousers has to be updated because of
  iconv library conflict.

 -- Hiroki

Thank you so much, after update r335655 work fine :)

# tpm_version
  TPM 1.2 Version Info:
  Chip Version:1.2.8.32
  Spec Level:  2
  Errata Revision: 3
  TPM Vendor ID:   STM
  TPM Version: 0101
  Manufacturer Info:   53544d20
___
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 you maintain which are out of date

2013-12-05 Thread portscout
Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
misc/dphys-config   | 20100216| 
20130301~current
+-+
print/pmw   | 4.26| 4.27
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

If wish to stop receiving portscout reminders, please contact
portsc...@freebsd.org

Thanks.
___
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


Force Dependent ports OPTIONS

2013-12-05 Thread Muhammad Moinur Rahman
Hi,

Let us suppose I am porting an application which depends on Openssl. But
not only OpenSSL, OpenSSL has to have some options enabled which are not
enabled by default. How can I force changing the knob?

Slave port is an option I have thought. But anything else? Thanks in
advance.

Regards,
Muhammad
___
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: Force Dependent ports OPTIONS

2013-12-05 Thread Baptiste Daroussin
On Thu, Dec 05, 2013 at 05:42:15PM +0600, Muhammad Moinur Rahman wrote:
 Hi,
 
 Let us suppose I am porting an application which depends on Openssl. But
 not only OpenSSL, OpenSSL has to have some options enabled which are not
 enabled by default. How can I force changing the knob?
 
 Slave port is an option I have thought. But anything else? Thanks in
 advance.
 

Creating a slave port will be a nightmare for openssl, what option are you
depending on? is it intrusive, does it make sense to have it by default?

Those are the questions, depending on answers the good way could be to remove
the option from the openssl port and activate by default the feature.

regards,
Bapt


pgppwVgeSaAA_.pgp
Description: PGP signature


Re: Force Dependent ports OPTIONS

2013-12-05 Thread Muhammad Moinur Rahman
Hi Bapte,

RFC3779.

BR,
Muhammad


On Thu, Dec 5, 2013 at 5:45 PM, Baptiste Daroussin b...@freebsd.org wrote:

 On Thu, Dec 05, 2013 at 05:42:15PM +0600, Muhammad Moinur Rahman wrote:
  Hi,
 
  Let us suppose I am porting an application which depends on Openssl. But
  not only OpenSSL, OpenSSL has to have some options enabled which are not
  enabled by default. How can I force changing the knob?
 
  Slave port is an option I have thought. But anything else? Thanks in
  advance.
 

 Creating a slave port will be a nightmare for openssl, what option are you
 depending on? is it intrusive, does it make sense to have it by default?

 Those are the questions, depending on answers the good way could be to
 remove
 the option from the openssl port and activate by default the feature.

 regards,
 Bapt

___
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: Ports via svn, make fetchindex and make compatibility with NetBSD

2013-12-05 Thread Thomas Mueller
  So could I run make fetchindex from NetBSD even if I don't attempt to 
  actually build ports from NetBSD?

  I would have to point the MAKECONF to FreeBSD's /etc/make.conf rather than 
  use NetBSD's /etc/mk.conf which is specific to NetBSD.

  Or is it safe to skip make fetchindex entirely?

 It is safe :)

 regards,
 Bapt

Now I can feel more comfortable, I trust your insider knowledge.

I still would have to make fetchlist from FreeBSD, then fetch from NetBSD, then 
boot back to FreeBSD to compile/build.

Sort of cloak-and-dagger.

Better would be if I could get Hiro H50191 USB wireless adapter to work with 
driver rsu, could even try ndis as fallback and to see if that works.

I haven't yet tried with my new TP-Link wireless router that replaced a failing 
Netgear router.

Tom
___
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: opencv update

2013-12-05 Thread Mark Atkinson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/04/2013 17:38, Andrew W. Nosenko wrote:
 PS. @Mark: cvCreateImageHeader, symbol, which test program tries to
 find in opencv-core.so library, exists there and exported indeed.
 It absent in the output of plain nm (or 'nm -a' in your case) just
 because library is heavy stripped (removed anything unneeded for
 ld.so).  If use 'nm -D', you will see that symbol.

Interesting.  Thank you.   Looks like I have some scripts to change.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKgkaEACgkQrDN5kXnx8yY86QCeMHjT4LS/mk6SRB9GTqZHbBXO
IbYAn1CYmVvYMrKRxhtE70lmtw64j9l4
=MLNR
-END PGP SIGNATURE-

___
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


Can't build openjdk6 under FreeBSD 10.0-BETA4 #2 r258782 amd64

2013-12-05 Thread Richard Kuhns
Hello,

I'm trying to build openjdk6-b28_6 and get the following failure.

I tried both with and without MAKE_JOBS_UNSAFE=yes. The extract below is with.


build-classes-javac:
[mkdir] Created dir:
/usr/ports/java/openjdk6/work/build/bsd-amd64/langtools/build/gensrc
[mkdir] Created dir:
/usr/ports/java/openjdk6/work/build/bsd-amd64/langtools/build/classes
 [pcompile] Generating 7 resource files to
/usr/ports/java/openjdk6/work/build/bsd-amd64/langtools/build/gensrc
 [copy] Copying 1 file to
/usr/ports/java/openjdk6/work/build/bsd-amd64/langtools/build/gensrc
 [pcompile] Generating 1 resource files to
/usr/ports/java/openjdk6/work/build/bsd-amd64/langtools/build/gensrc
[javac] Compiling 8 source files to
/usr/ports/java/openjdk6/work/build/bsd-amd64/langtools/build/classes
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000800a4e278, pid=41785, tid=101384
#
# JRE version: 6.0_32-b28
# Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode bsd-amd64 compressed 
oops)
# Problematic frame:
# C  [libthr.so.3+0x13278]  pthread_cond_signal+0x88
#
# Core dump written. Default location:
/usr/ports/java/openjdk6/work/langtools/make/core or core.41785
#
# An error report file with more information is saved as:
# /usr/ports/java/openjdk6/work/langtools/make/hs_err_pid41785.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#
gmake[4]: *** [build] Abort trap (core dumped)
gmake[4]: Leaving directory `/usr/ports/java/openjdk6/work/langtools/make'
gmake[3]: *** [langtools-build] Error 2
gmake[3]: Leaving directory `/usr/ports/java/openjdk6/work'
gmake[2]: *** [build_product_image] Error 2
gmake[2]: Leaving directory `/usr/ports/java/openjdk6/work'
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/java/openjdk6
*** Error code 1

Stop.
make: stopped in /usr/ports/java/openjdk6

-- 
Richard Kuhns r...@wintek.com Direct:   765-269-8541
Wintek Corporation Internet Support: 765-269-8503
427 N 6th Street   Consulting:   765-269-8504
Lafayette, IN 47901-2211   Accounting:   765-269-8502
___
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


Output change of 'pkg info' after 1.2.

2013-12-05 Thread Yasuhiro KIMURA
I noticed that output of 'pkg info' changed after version 1.2.

If I remember correctly, 1.1.x behaved as following:

- 'pkg info -q pkg-name' outputs package name with version.
- 'pkg info pkg-name' outputs package name with version, and comment.
- 'pkg info -f pkg-name' outputs full information.

But 1.2.1 works as following:

- 'pkg info -q pkg-name' outputs nothing.
- Both 'pkg info pkg-name' and 'pkg info -f pkg-name' outputs full
  information. 

Is this change intended one?

---
Yasuhiro KIMURA
___
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: Can't build openjdk6 under FreeBSD 10.0-BETA4 #2 r258782 amd64

2013-12-05 Thread Richard Kuhns
Sorry to follow up on my own post, but I tried removing openjdk6-b28_5 first and
the build for openjdk6-b28_6 succeeded.
-- 
Richard Kuhns r...@wintek.com Direct:   765-269-8541
Wintek Corporation Internet Support: 765-269-8503
427 N 6th Street   Consulting:   765-269-8504
Lafayette, IN 47901-2211   Accounting:   765-269-8502
___
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


Trouble building some perl ports

2013-12-05 Thread Steve McCoy
Hello,

I'm having some trouble creating packages for some perl ports. They seem to
be confused about where to place files. For example, p5-libwww:

===   Generating temporary packing list
Installing
/var/ports/usr/ports/www/p5-libwww/work/stage/usr/local/lib/perl5/site_perl/5.12.4/LWP.pm

...

===  Building package for p5-libwww-6.05
Creating package
/var/ports/usr/ports/www/p5-libwww/work/p5-libwww-6.05.tbz
Registering depends: ...
tar: lib/perl5/site_perl/5.12/mach/auto/LWP/.packlist: Cannot stat: No
such file or directory
tar: lib/perl5/site_perl/5.12/LWP.pm: Cannot stat: No such file or
directory

@INC contains /usr/local/lib/perl/site_perl/5.12.4 and that's where all of
the other perl packages had been installed, so the staging step seems
correct to me. I don't know why the packaging step is expecting anything to
be staged in a 5.12 path instead of 5.12.4. Does anybody have an idea how
it could get into this situation? Could the be because my installed perl is
older than these packages? (It's from before threads became a default
option.)


Any help would be appreciated!
___
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: Output change of 'pkg info' after 1.2.

2013-12-05 Thread Michael Gmelin
On Fri, 06 Dec 2013 00:13:38 +0900 (JST)
Yasuhiro KIMURA y...@utahime.org wrote:

 I noticed that output of 'pkg info' changed after version 1.2.
 
 If I remember correctly, 1.1.x behaved as following:
 
 - 'pkg info -q pkg-name' outputs package name with version.
 - 'pkg info pkg-name' outputs package name with version, and comment.
 - 'pkg info -f pkg-name' outputs full information.
 
 But 1.2.1 works as following:
 
 - 'pkg info -q pkg-name' outputs nothing.
 - Both 'pkg info pkg-name' and 'pkg info -f pkg-name' outputs full
   information. 

Just tested, pkg 1.1.4 vs. 1.2.1

pkg info -q pkg-name is identical on both, but -f vs no parameter
definitely changed and this seems like a bug to me.

 
 Is this change intended one?
 
 ---
 Yasuhiro KIMURA
 ___
 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





-- 
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: Trouble building some perl ports

2013-12-05 Thread William Grzybowski
Did you follow:

20130612:
  AFFECTS: users of lang/perl* and any port that depends on it
  AUTHOR: a...@freebsd.org

  lang/perl5.12 has been upgraded from version 5.12.4 to 5.12.5
  lang/perl5.14 has been upgraded from version 5.14.2 to 5.14.4
  lang/perl5.16 has been upgraded from version 5.16.2 to 5.16.3

  The directory structure where Perl is installed has also been modified:
  major.minor is now used instead of major.minor.patchlevel.

  The perl-after-upgrade script has been removed.

  Please rebuild all Perl ports and all ports that depend on it:

  # portmaster -r perl
or
  # portupgrade -rf perl
or
  # pkg install -fR perl


On Thu, Dec 5, 2013 at 1:41 PM, Steve McCoy mcco...@gmail.com wrote:

 Hello,

 I'm having some trouble creating packages for some perl ports. They seem to
 be confused about where to place files. For example, p5-libwww:

 ===   Generating temporary packing list
 Installing

 /var/ports/usr/ports/www/p5-libwww/work/stage/usr/local/lib/perl5/site_perl/5.12.4/LWP.pm

 ...

 ===  Building package for p5-libwww-6.05
 Creating package
 /var/ports/usr/ports/www/p5-libwww/work/p5-libwww-6.05.tbz
 Registering depends: ...
 tar: lib/perl5/site_perl/5.12/mach/auto/LWP/.packlist: Cannot stat: No
 such file or directory
 tar: lib/perl5/site_perl/5.12/LWP.pm: Cannot stat: No such file or
 directory

 @INC contains /usr/local/lib/perl/site_perl/5.12.4 and that's where all of
 the other perl packages had been installed, so the staging step seems
 correct to me. I don't know why the packaging step is expecting anything to
 be staged in a 5.12 path instead of 5.12.4. Does anybody have an idea how
 it could get into this situation? Could the be because my installed perl is
 older than these packages? (It's from before threads became a default
 option.)


 Any help would be appreciated!
 ___
 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




-- 
William Grzybowski
--
Curitiba/PR - Brasil
___
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: Trouble building some perl ports

2013-12-05 Thread Steve McCoy
Ah, that's almost certainly it. When I searched through UPDATING I was too
focused on the specific ports. Thanks!


On Thu, Dec 5, 2013 at 10:44 AM, William Grzybowski willia...@gmail.comwrote:

 Did you follow:

 20130612:
   AFFECTS: users of lang/perl* and any port that depends on it
   AUTHOR: a...@freebsd.org

   lang/perl5.12 has been upgraded from version 5.12.4 to 5.12.5
   lang/perl5.14 has been upgraded from version 5.14.2 to 5.14.4
   lang/perl5.16 has been upgraded from version 5.16.2 to 5.16.3

   The directory structure where Perl is installed has also been modified:
   major.minor is now used instead of major.minor.patchlevel.

   The perl-after-upgrade script has been removed.

   Please rebuild all Perl ports and all ports that depend on it:

   # portmaster -r perl
 or
   # portupgrade -rf perl
 or
   # pkg install -fR perl


 On Thu, Dec 5, 2013 at 1:41 PM, Steve McCoy mcco...@gmail.com wrote:

 Hello,

 I'm having some trouble creating packages for some perl ports. They seem
 to
 be confused about where to place files. For example, p5-libwww:

 ===   Generating temporary packing list
 Installing

 /var/ports/usr/ports/www/p5-libwww/work/stage/usr/local/lib/perl5/site_perl/5.12.4/LWP.pm

 ...

 ===  Building package for p5-libwww-6.05
 Creating package
 /var/ports/usr/ports/www/p5-libwww/work/p5-libwww-6.05.tbz
 Registering depends: ...
 tar: lib/perl5/site_perl/5.12/mach/auto/LWP/.packlist: Cannot stat: No
 such file or directory
 tar: lib/perl5/site_perl/5.12/LWP.pm: Cannot stat: No such file or
 directory

 @INC contains /usr/local/lib/perl/site_perl/5.12.4 and that's where all of
 the other perl packages had been installed, so the staging step seems
 correct to me. I don't know why the packaging step is expecting anything
 to
 be staged in a 5.12 path instead of 5.12.4. Does anybody have an idea how
 it could get into this situation? Could the be because my installed perl
 is
 older than these packages? (It's from before threads became a default
 option.)


 Any help would be appreciated!
 ___
 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




 --
 William Grzybowski
 --
 Curitiba/PR - Brasil

___
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: Output change of 'pkg info' after 1.2.

2013-12-05 Thread Baptiste Daroussin
On Thu, Dec 05, 2013 at 04:36:00PM +0100, Michael Gmelin wrote:
 On Fri, 06 Dec 2013 00:13:38 +0900 (JST)
 Yasuhiro KIMURA y...@utahime.org wrote:
 
  I noticed that output of 'pkg info' changed after version 1.2.
  
  If I remember correctly, 1.1.x behaved as following:
  
  - 'pkg info -q pkg-name' outputs package name with version.
  - 'pkg info pkg-name' outputs package name with version, and comment.
  - 'pkg info -f pkg-name' outputs full information.
  
  But 1.2.1 works as following:
  
  - 'pkg info -q pkg-name' outputs nothing.
  - Both 'pkg info pkg-name' and 'pkg info -f pkg-name' outputs full
information. 
 
 Just tested, pkg 1.1.4 vs. 1.2.1
 
 pkg info -q pkg-name is identical on both, but -f vs no parameter
 definitely changed and this seems like a bug to me.
 

It is not a bug, but intended as requested by a lot of users. To mimic the
pkg_info behaviour.

pkg info -q shows nothing on purpose as well as pkg info -q is used by the
scripts like portmaster or by the ports tree and only the return value is
checked
0 means something was found 1 means nothing was found.

regards,
Bapt


pgpZi8Bal1e1Q.pgp
Description: PGP signature


Re: Output change of 'pkg info' after 1.2.

2013-12-05 Thread Yasuhiro KIMURA
From: Baptiste Daroussin b...@freebsd.org
Subject: Re: Output change of 'pkg info' after 1.2.
Date: Thu, 5 Dec 2013 17:24:09 +0100

 On Thu, Dec 05, 2013 at 04:36:00PM +0100, Michael Gmelin wrote:
 On Fri, 06 Dec 2013 00:13:38 +0900 (JST)
 Yasuhiro KIMURA y...@utahime.org wrote:
 
  I noticed that output of 'pkg info' changed after version 1.2.
  
  If I remember correctly, 1.1.x behaved as following:
  
  - 'pkg info -q pkg-name' outputs package name with version.
  - 'pkg info pkg-name' outputs package name with version, and comment.
  - 'pkg info -f pkg-name' outputs full information.
  
  But 1.2.1 works as following:
  
  - 'pkg info -q pkg-name' outputs nothing.
  - Both 'pkg info pkg-name' and 'pkg info -f pkg-name' outputs full
information. 
 
 Just tested, pkg 1.1.4 vs. 1.2.1
 
 pkg info -q pkg-name is identical on both, but -f vs no parameter
 definitely changed and this seems like a bug to me.
 
 
 It is not a bug, but intended as requested by a lot of users. To mimic the
 pkg_info behaviour.
 
 pkg info -q shows nothing on purpose as well as pkg info -q is used by the
 scripts like portmaster or by the ports tree and only the return value is
 checked
 0 means something was found 1 means nothing was found.

Thank you for explanation.

Then I have one question. Is there any way to get same output as 
'pkg info pkg-name' of 1.1.x? I tried some combination of options but
could not find proper one.

Regards.

---
Yasuhiro KIMURA
___
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: Position independent code and global destructor order (devel/ice)

2013-12-05 Thread Konstantin Belousov
On Sat, Nov 30, 2013 at 10:34:27PM +0100, Michael Gmelin wrote:
 We discussed this topic about half a year ago, but came to no
 conclusion. I CCed everyone who participated in the discussion back
 then.
 
 Since 10-RELEASE is around the corner and I'm trying to get devel/ice
 working on it, one more attempt:
 
 When -fPIC is used on objects that are linked into an executable (and
 not a shared library), the static destruction order guaranteed by the
 C++ standard is not followed. There is also no warning or error while
 building/linking. The end-result of this problem is subtle and will
 only surface on exit (at the end of runtime). When porting bigger
 projects (like Ice in my case), finding all those problems is really
 hard, since they're not reported at build time. It's not uncommon to
 set global CFLAGS in a build, and not every projects distinguishes
 between objects which will end up in shared libraries and those which
 will be linked to executables directly.
 
 In case of Ice this leads to crashes (bus error etc.) on exit,
 depending on the projects the results of this could be quite severe.
 The fix is to go through every Makefile of the project, basically
 creating a big patch that touches everything to work around this
 issue, hoping not to forget a single object file. Every user of the library
 and the generated code will have to do the same in their
 Makefiles/Cmakefiles/Jamfiles etc. It makes porting and using C++ code
 on FreeBSD hard and software that runs fine on other platforms will
 break for reasons people won't understand/will take them forever to
 debug.
 
 So is there anything that could be done to:
 
 a) Make -fPIC just work like it did before r211706?
or if this is not an option.
 b) Report an error when linking the executable, so that objects built
with -fPIC can't be used in that case/barf at compile time.
 
 I would appreciate any kind of constructive response at this point, the
 last I got was back in June: I think that we could revert the
 termination calls to the functions from the dso being unloaded, but
 this is quite unfortunate, since it will restore the endless series of
 'segfault at the process termination' reports.

If you provided link to the original discussion, it would take much less
energy and time to refresh the memory.

I looked over this, and I think that r211706 can be refined, by only
calling atexit hooks for 'wrong' dso when the call to __cxa_finalize()
is from the real dlclose(), as opposed to the process exit.  For me,
with the world where the patch is applied, your 'major tom' test passes.

Of course, when dso1 registers __cxa_atexit hook located in dso2, and
dso2 is unloaded before dso1, the hooks are called in the wrong order
still, but the only alternatives there are either crash or do not call
such hooks at all.

diff --git a/include/dlfcn.h b/include/dlfcn.h
index c508843..38957e2 100644
--- a/include/dlfcn.h
+++ b/include/dlfcn.h
@@ -53,7 +53,8 @@
 #defineRTLD_DI_SERINFO 4   /* Obtain search path info. */
 #defineRTLD_DI_SERINFOSIZE 5   /*  ... query for required 
space. */
 #defineRTLD_DI_ORIGIN  6   /* Obtain object origin */
-#defineRTLD_DI_MAX RTLD_DI_ORIGIN
+#defineRTLD_DI_GLOBALEXIT  7
+#defineRTLD_DI_MAX RTLD_DI_GLOBALEXIT
 
 /*
  * Special handle arguments for dlsym()/dlinfo().
diff --git a/lib/libc/stdlib/atexit.c b/lib/libc/stdlib/atexit.c
index 18c31c3..b08d1de 100644
--- a/lib/libc/stdlib/atexit.c
+++ b/lib/libc/stdlib/atexit.c
@@ -37,6 +37,7 @@ static char sccsid[] = @(#)atexit.c  8.2 (Berkeley) 7/3/94;
 __FBSDID($FreeBSD$);
 
 #include namespace.h
+#include dlfcn.h
 #include link.h
 #include stddef.h
 #include stdlib.h
@@ -162,8 +163,10 @@ __cxa_finalize(void *dso)
struct dl_phdr_info phdr_info;
struct atexit *p;
struct atexit_fn fn;
-   int n, has_phdr;
+   int n, has_phdr, global_exit;
 
+   global_exit = 0;
+   dlinfo(dso, RTLD_DI_GLOBALEXIT, global_exit);
if (dso != NULL)
has_phdr = _rtld_addr_phdr(dso, phdr_info);
else
@@ -177,8 +180,9 @@ __cxa_finalize(void *dso)
fn = p-fns[n];
if (dso != NULL  dso != fn.fn_dso) {
/* wrong DSO ? */
-   if (!has_phdr || !__elf_phdr_match_addr(
-   phdr_info, fn.fn_ptr.cxa_func))
+   if (!has_phdr || global_exit ||
+   !__elf_phdr_match_addr(phdr_info,
+   fn.fn_ptr.cxa_func))
continue;
}
/*
@@ -200,6 +204,6 @@ __cxa_finalize(void *dso)
if (dso == NULL)
_MUTEX_DESTROY(atexit_mutex);
 
-   if (has_phdr  __pthread_cxa_finalize != NULL)
+   if (has_phdr  !global_exit  

openmpi doesn't install under F10

2013-12-05 Thread Dennis Glatting


OpenMPI fails to install under FreeBSD-10 BETA4. It previously installed 
under BETA3. The key difference appears to be version _1 vs _2. Data 
follows.


The system:

Coke# uname -a
FreeBSD Coke 10.0-BETA4 FreeBSD 10.0-BETA4 #1 r258932: Wed Dec  4 14:57:28 
PST 2013 root@Coke:/usr/obj/usr/src/sys/XYZZY-FBSD10  amd64


Key part of the Makefile:

PORTNAME=   openmpi
DISTVERSION=1.7.3
PORTREVISION=   2

The relevant diagnostic output:

Coke# make -dA install
...
+ echo '===   Registering installation for openmpi-1.7.3_2'
Execute: '/usr/bin/env FORCE_POST=rmdir kldxref mkfontscale mkfontdir 
fc-cache  fonts.dir fonts.scale gtk-update-icon-cache  gio-querymodules 
gtk-query-immodules  ldconfig  load-octave-pkg  update-desktop-database 
update-mime-database  gdk-pixbuf-query-loaders catalog.ports 
glib-compile-schemas /usr/local/sbin/pkg-static register -i 
/usr/ports/net/openmpi/work/stage -m /usr/ports/net/openmpi/work/.metadir 
-f /usr/ports/net/openmpi/work/.PLIST.mktmp'
+ /usr/bin/env 'FORCE_POST=rmdir kldxref mkfontscale mkfontdir fc-cache 
fonts.dir fonts.scale gtk-update-icon-cache  gio-querymodules 
gtk-query-immodules  ldconfig  load-octave-pkg  update-desktop-database 
update-mime-database  gdk-pixbuf-query-loaders catalog.ports 
glib-compile-schemas' /usr/local/sbin/pkg-static register -i 
/usr/ports/net/openmpi/work/stage -m /usr/ports/net/openmpi/work/.metadir 
-f /usr/ports/net/openmpi/work/.PLIST.mktmp
pkg-static: 
lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/ompi-iof): 
No such file or directory
pkg-static: 
lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/ompi-probe): 
No such file or directory
pkg-static: 
lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/ompi-profiler): 
No such file or directory
pkg-static: 
lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/orte-bootproxy.sh): 
No such file or directory
pkg-static: 
lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/orte-iof): 
No such file or directory



pkg info from working installation:

root@Monster:~ # pkg info | grep -i openmpi
openmpi-1.7.3_1High Performance Message Passing Library


___
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: Position independent code and global destructor order (devel/ice)

2013-12-05 Thread Michael Gmelin
On Thu, 5 Dec 2013 19:07:28 +0200
Konstantin Belousov kostik...@gmail.com wrote:

 If you provided link to the original discussion, it would take much
 less energy and time to refresh the memory.

Forgot to include it, sorry. Thanks for you response and the patch.

 
 I looked over this, and I think that r211706 can be refined, by only
 calling atexit hooks for 'wrong' dso when the call to __cxa_finalize()
 is from the real dlclose(), as opposed to the process exit.  For me,
 with the world where the patch is applied, your 'major tom' test
 passes.

Makes sense.

 
 Of course, when dso1 registers __cxa_atexit hook located in dso2, and
 dso2 is unloaded before dso1, the hooks are called in the wrong order
 still, but the only alternatives there are either crash or do not call
 such hooks at all.

Sounds like a good solution. PHP (and similar) crashes are avoided
while clean code isn't affected. I will try the patch in my specific
use case to make sure it works there as well.

-- 
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: openmpi doesn't install under F10

2013-12-05 Thread Danilo E. Gondolfo
On 12/05/13 15:17, Dennis Glatting wrote:

 OpenMPI fails to install under FreeBSD-10 BETA4. It previously
 installed under BETA3. The key difference appears to be version _1 vs
 _2. Data follows.

 The system:

 Coke# uname -a
 FreeBSD Coke 10.0-BETA4 FreeBSD 10.0-BETA4 #1 r258932: Wed Dec  4
 14:57:28 PST 2013 root@Coke:/usr/obj/usr/src/sys/XYZZY-FBSD10  amd64

 Key part of the Makefile:

 PORTNAME=   openmpi
 DISTVERSION=1.7.3
 PORTREVISION=   2

 The relevant diagnostic output:

 Coke# make -dA install
 ...
 + echo '===   Registering installation for openmpi-1.7.3_2'
 Execute: '/usr/bin/env FORCE_POST=rmdir kldxref mkfontscale mkfontdir
 fc-cache  fonts.dir fonts.scale gtk-update-icon-cache 
 gio-querymodules gtk-query-immodules  ldconfig  load-octave-pkg 
 update-desktop-database update-mime-database  gdk-pixbuf-query-loaders
 catalog.ports glib-compile-schemas /usr/local/sbin/pkg-static
 register -i /usr/ports/net/openmpi/work/stage -m
 /usr/ports/net/openmpi/work/.metadir -f
 /usr/ports/net/openmpi/work/.PLIST.mktmp'
 + /usr/bin/env 'FORCE_POST=rmdir kldxref mkfontscale mkfontdir
 fc-cache fonts.dir fonts.scale gtk-update-icon-cache  gio-querymodules
 gtk-query-immodules  ldconfig  load-octave-pkg 
 update-desktop-database update-mime-database  gdk-pixbuf-query-loaders
 catalog.ports glib-compile-schemas' /usr/local/sbin/pkg-static
 register -i /usr/ports/net/openmpi/work/stage -m
 /usr/ports/net/openmpi/work/.metadir -f
 /usr/ports/net/openmpi/work/.PLIST.mktmp
 pkg-static:
 lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/ompi-iof):
 No such file or directory
 pkg-static:
 lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/ompi-probe):
 No such file or directory
 pkg-static:
 lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/ompi-profiler):
 No such file or directory
 pkg-static:
 lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/orte-bootproxy.sh):
 No such file or directory
 pkg-static:
 lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/orte-iof):
 No such file or directory


 pkg info from working installation:

 root@Monster:~ # pkg info | grep -i openmpi
 openmpi-1.7.3_1High Performance Message Passing Library


 ___
 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


Hello Dennis,

I'm a bit confused. The port net/openmpi installs the version 1.6.5. The
version 1.7.3 is installed by net/openmpi-devel.

Look:

$ pkg info | grep openmpi
openmpi-1.6.5_2High Performance Message Passing Library

and with net/openmpi-devel installed:

$ pkg info | grep openmpi
openmpi-devel-1.7.3High Performance Message Passing Library


Did you edit the Makefile?

___
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: openmpi doesn't install under F10

2013-12-05 Thread Danilo E. Gondolfo
On 12/05/13 16:00, Dennis Glatting wrote:
 
 
 On Thu, 5 Dec 2013, Danilo E. Gondolfo wrote:
 
 On 12/05/13 15:17, Dennis Glatting wrote:

 OpenMPI fails to install under FreeBSD-10 BETA4. It previously
 installed under BETA3. The key difference appears to be version _1 vs
 _2. Data follows.

 The system:

 Coke# uname -a
 FreeBSD Coke 10.0-BETA4 FreeBSD 10.0-BETA4 #1 r258932: Wed Dec  4
 14:57:28 PST 2013 root@Coke:/usr/obj/usr/src/sys/XYZZY-FBSD10  amd64

 Key part of the Makefile:

 PORTNAME=   openmpi
 DISTVERSION=1.7.3
 PORTREVISION=   2

 The relevant diagnostic output:

 Coke# make -dA install
 ...
 + echo '===   Registering installation for openmpi-1.7.3_2'
 Execute: '/usr/bin/env FORCE_POST=rmdir kldxref mkfontscale mkfontdir
 fc-cache  fonts.dir fonts.scale gtk-update-icon-cache
 gio-querymodules gtk-query-immodules  ldconfig  load-octave-pkg
 update-desktop-database update-mime-database  gdk-pixbuf-query-loaders
 catalog.ports glib-compile-schemas /usr/local/sbin/pkg-static
 register -i /usr/ports/net/openmpi/work/stage -m
 /usr/ports/net/openmpi/work/.metadir -f
 /usr/ports/net/openmpi/work/.PLIST.mktmp'
 + /usr/bin/env 'FORCE_POST=rmdir kldxref mkfontscale mkfontdir
 fc-cache fonts.dir fonts.scale gtk-update-icon-cache  gio-querymodules
 gtk-query-immodules  ldconfig  load-octave-pkg
 update-desktop-database update-mime-database  gdk-pixbuf-query-loaders
 catalog.ports glib-compile-schemas' /usr/local/sbin/pkg-static
 register -i /usr/ports/net/openmpi/work/stage -m
 /usr/ports/net/openmpi/work/.metadir -f
 /usr/ports/net/openmpi/work/.PLIST.mktmp
 pkg-static:
 lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/ompi-iof):

 No such file or directory
 pkg-static:
 lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/ompi-probe):

 No such file or directory
 pkg-static:
 lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/ompi-profiler):

 No such file or directory
 pkg-static:
 lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/orte-bootproxy.sh):

 No such file or directory
 pkg-static:
 lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/orte-iof):

 No such file or directory


 pkg info from working installation:

 root@Monster:~ # pkg info | grep -i openmpi
 openmpi-1.7.3_1High Performance Message Passing Library


 ___
 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


 Hello Dennis,

 I'm a bit confused. The port net/openmpi installs the version 1.6.5. The
 version 1.7.3 is installed by net/openmpi-devel.

 Look:

 $ pkg info | grep openmpi
 openmpi-1.6.5_2High Performance Message Passing Library

 and with net/openmpi-devel installed:

 $ pkg info | grep openmpi
 openmpi-devel-1.7.3High Performance Message Passing Library


 Did you edit the Makefile?

 
 Thanks. Apparently. I deleted the Makefile and rechecked it out. That
 version is 1.6.5. My goof. Thanks.
 

Ok :)

___
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


[games/ofortune] CFT and pending issues

2013-12-05 Thread A.J. 'Fonz' van Werven
A short recap for those of you who are subscribed to freebsd-ports@ but
not freebsd-stable@: when I opened my inbox this morning I found a typical
WTF thread: the (hardly) offensive fortune cookies have been kicked out
of 10-BETA4. Since I (and many others) find this Just Plain Stupid (tm) I
created a port to bring some sanity back into fortune(6).

Anyone running FreeBSD 10-BETA4 feel free to test the port and comment on
it before I file the PR asking for it to be committed.

A shar patch can be found here:
http://www.skysmurf.nl/comp/FreeBSD/files/ofortune.shar

Or alternatively, a tarball can be found in the same place:
http://www.skysmurf.nl/comp/FreeBSD/files/ofortune.tar.gz

To extract the shar file:
# cd /usr/ports/games
# sh /path/to/shar-file

Or alternatively, to extract the tarball:
# cd /usr/ports/games
# tar xzvf /path/to/tarball

Install via your favourite method, e.g.

# cd /usr/ports/games/ofortune
# make install
or
# portmaster games/ofortune

PENDING ISSUES:

-1-
It's tentatively called ofortune. If you can think of a better name, then
by all means shoot.

-2-
The accompanying webpage is crap. This is no priority ;-)

-3-
I have found the instructions for changing and/or adding to the fortune
files but haven't tested them yet.

-4-
I wanted to mark the port as IGNORE for versions of FreeBSD prior to
10-BETA4. But this breaks stuff (see point 6) and I need to know exactly
what the version number (OSVERSION) is for 10-BETA4.

-5-
Currently the port installs the offensive fortunes into
/usr/local/share/ofortune, requiring every user to add that directory to
their FORTUNE_PATH (hence the pkg-message). I tried adding an OPTION that
would install it into the base /usr/share/games/fortune, but that again
breaks stuff, see point 6.

-6-
It appears that for some reason conditionals don't work in the Makefile.
For your reference, I have added the Makefile below, with the parts
commented out that I think should work but don't. In both cases I get
Malformed conditional errors. Any thoughts?

Regards,

AvW (fonz)

[begin /usr/ports/games/ofortune/Makefile]
# $FreeBSD$

PORTNAME=   ofortune
PORTVERSION=0.99.0
CATEGORIES= games
MASTER_SITES=   http://www.skysmurf.nl/comp/FreeBSD/distfiles/

MAINTAINER= free...@skysmurf.nl
COMMENT=The offensive fortune cookies that used to be in base.

###
# This is supposed to work but doesn't.
###
#OPTIONS_DEFINE=BASE
#OPTIONS_DEFAULT=
#BASE_DESC= To install into the base system rather than /usr/local.
#
#.include bsd.port.options.mk
#
#.if ${PORT_OPTIONS:BASE}
#DATADIR=   /usr/share/games/fortune
#.else
PLIST_DIRS= ${DATADIR}
#.endif

PLIST_FILES=${DATADIR}/fortunes-o \
${DATADIR}/fortunes-o.dat \
${DATADIR}/murphy-o \
${DATADIR}/murphy-o.dat

NO_BUILD=   yes
NO_INSTALL= yes

###
# This is supposed to work but doesn't.
#
# 702106 has been copied from an example, I need the right number for 10-BETA4.
#
#.if ${OSVERSION}  702106
#IGNORE=For versions prior to 10-BETA4 this is still in base.
#.endif
###

post-install:
${MKDIR} ${STAGEDIR}${DATADIR}
${INSTALL_DATA} ${WRKSRC}/* ${STAGEDIR}${DATADIR}

.include bsd.port.mk
[end /usr/ports/games/ofortune/Makefile]

-- 
I'm not completely useless, I can be used as a bad example.


pgppfMUJzytPi.pgp
Description: PGP signature


Differences between iconv from ports and iconv in base (transliteration)

2013-12-05 Thread Michael Gmelin
I'm in the process of changing ports from ports iconv to iconv in base.
I noticed that transliteration doesn't work in base as it does with
iconv from ports. Examples:

T\xc5\xbdst
ports: TZst
base: Tst

T\xe2\x82\xacst
ports: TEURst
base: Tst

Conversion done using:
iconv_open(ISO8859-1//IGNORE//TRANSLIT, UTF-8);

Any ideas?

-- 
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: [games/ofortune] CFT and pending issues

2013-12-05 Thread Andrew Berg
On 2013.12.05 15:54, A.J. 'Fonz' van Werven wrote:
 A short recap for those of you who are subscribed to freebsd-ports@ but
 not freebsd-stable@: when I opened my inbox this morning I found a typical
 WTF thread: the (hardly) offensive fortune cookies have been kicked out
 of 10-BETA4. Since I (and many others) find this Just Plain Stupid (tm) I
 created a port to bring some sanity back into fortune(6).
Thank you for making this port. I was quite saddened when these fortunes were 
removed.

 Anyone running FreeBSD 10-BETA4 feel free to test the port and comment on
 it before I file the PR asking for it to be committed.
I will test it this weekend.

 PENDING ISSUES:
 
 -1-
 It's tentatively called ofortune. If you can think of a better name, then
 by all means shoot.
Going by the other fortune file ports, misc/fortune-offensive or something very 
similar would be more appropriate.
It's not really a game in itself and the others are in misc, so misc is 
probably more appropriate.

 -4-
 I wanted to mark the port as IGNORE for versions of FreeBSD prior to
 10-BETA4. But this breaks stuff (see point 6) and I need to know exactly
 what the version number (OSVERSION) is for 10-BETA4.
The fortunes were removed in one of the ALPHA releases if not before then 
(certainly before 10 was branched to -STABLE), so I'm sure it's
fine to simply target 10.
Anyone still running a version of 10 from when it was still -CURRENT can expect 
problems anyway.

 COMMENT=  The offensive fortune cookies that used to be in base.
Perhaps it would be better to specify the version - e.g., The offensive 
fortune cookies present the 9.x base system that were removed in 10.x.
___
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: Position independent code and global destructor order (devel/ice)

2013-12-05 Thread Michael Gmelin


On Thu, 5 Dec 2013 18:20:58 +0100
Michael Gmelin free...@grem.de wrote:

 On Thu, 5 Dec 2013 19:07:28 +0200
 Konstantin Belousov kostik...@gmail.com wrote:
 
  If you provided link to the original discussion, it would take much
  less energy and time to refresh the memory.
 
 Forgot to include it, sorry. Thanks for you response and the patch.
 
  
  I looked over this, and I think that r211706 can be refined, by only
  calling atexit hooks for 'wrong' dso when the call to
  __cxa_finalize() is from the real dlclose(), as opposed to the
  process exit.  For me, with the world where the patch is applied,
  your 'major tom' test passes.
 
 Makes sense.
 
  
  Of course, when dso1 registers __cxa_atexit hook located in dso2,
  and dso2 is unloaded before dso1, the hooks are called in the wrong
  order still, but the only alternatives there are either crash or do
  not call such hooks at all.
 
 Sounds like a good solution. PHP (and similar) crashes are avoided
 while clean code isn't affected. I will try the patch in my specific
 use case to make sure it works there as well.
 

I tested your patch on 10-BETA2 and 10-BETA3. I built our complete
production environment from scratch, ran a huge number of unit and
integration tests. Everything works as expected, including Ice's
Schwarz Counter implementation
(http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Nifty_Counter).

So as far as I can tell this fixes the problem, while still
accomplishing the goals of r211706.

Thanks for 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


Re: Differences between iconv from ports and iconv in base (transliteration)

2013-12-05 Thread Michael Gmelin
On Fri, 6 Dec 2013 00:15:54 +0100
Michael Gmelin free...@grem.de wrote:

 I'm in the process of changing ports from ports iconv to iconv in
 base. I noticed that transliteration doesn't work in base as it does
 with iconv from ports. Examples:
 
 T\xc5\xbdst
 ports: TZst
 base: Tst
 
 T\xe2\x82\xacst
 ports: TEURst
 base: Tst
 
 Conversion done using:
 iconv_open(ISO8859-1//IGNORE//TRANSLIT, UTF-8);
 
 Any ideas?
 

I just checked /usr/src/lib/libc/iconv, it says in iconv_open:

/*
 * Remove anything following a //, as these are options (like
 * //ignore, //translate, etc) and we just don't handle them.
 * This is for compatibility with software that uses these
 * blindly.
 */

So basically any software that depends on using these options
will break.

The porters handbook doesn't mention the fact that converters/libiconv
and native iconv are not equivalent [1].

I think this is problematic.

[1] 
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/using-iconv.html

-- 
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: Position independent code and global destructor order (devel/ice)

2013-12-05 Thread Konstantin Belousov
On Fri, Dec 06, 2013 at 03:25:52AM +0100, Michael Gmelin wrote:
 I tested your patch on 10-BETA2 and 10-BETA3. I built our complete
 production environment from scratch, ran a huge number of unit and
 integration tests. Everything works as expected, including Ice's
 Schwarz Counter implementation
 (http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Nifty_Counter).
 
 So as far as I can tell this fixes the problem, while still
 accomplishing the goals of r211706.

Great, thank you.

I think that the patch can be further simplified.  From what I understand
about __cxa_finalize(3) protocol, confirmed by LSB, __cxa_finalize(NULL)
must only be called at the process exit, once.  Than, libc can use the
call as an indication of the final call to finalize, avoiding need for
help from rtld.

Please test the patch below.  It is enough to rebuild libc only.

diff --git a/lib/libc/stdlib/atexit.c b/lib/libc/stdlib/atexit.c
index 18c31c3..01d09fe 100644
--- a/lib/libc/stdlib/atexit.c
+++ b/lib/libc/stdlib/atexit.c
@@ -151,6 +151,8 @@ __cxa_atexit(void (*func)(void *), void *arg, void *dso)
 #pragma weak __pthread_cxa_finalize
 void __pthread_cxa_finalize(const struct dl_phdr_info *);
 
+static int global_exit;
+
 /*
  * Call all handlers registered with __cxa_atexit for the shared
  * object owning 'dso'.  Note: if 'dso' is NULL, then all remaining
@@ -164,10 +166,12 @@ __cxa_finalize(void *dso)
struct atexit_fn fn;
int n, has_phdr;
 
-   if (dso != NULL)
+   if (dso != NULL) {
has_phdr = _rtld_addr_phdr(dso, phdr_info);
-   else
+   } else {
has_phdr = 0;
+   global_exit = 1;
+   }
 
_MUTEX_LOCK(atexit_mutex);
for (p = __atexit; p; p = p-next) {
@@ -177,8 +181,9 @@ __cxa_finalize(void *dso)
fn = p-fns[n];
if (dso != NULL  dso != fn.fn_dso) {
/* wrong DSO ? */
-   if (!has_phdr || !__elf_phdr_match_addr(
-   phdr_info, fn.fn_ptr.cxa_func))
+   if (!has_phdr || global_exit ||
+   !__elf_phdr_match_addr(phdr_info,
+   fn.fn_ptr.cxa_func))
continue;
}
/*
@@ -200,6 +205,6 @@ __cxa_finalize(void *dso)
if (dso == NULL)
_MUTEX_DESTROY(atexit_mutex);
 
-   if (has_phdr  __pthread_cxa_finalize != NULL)
+   if (has_phdr  !global_exit  __pthread_cxa_finalize != NULL)
__pthread_cxa_finalize(phdr_info);
 }


pgpJHXoUccp0j.pgp
Description: PGP signature


Re: [games/ofortune] CFT and pending issues

2013-12-05 Thread Erich Dollansky
Hi,

On Thu, 5 Dec 2013 22:54:37 +0100
A.J. 'Fonz' van Werven free...@skysmurf.nl wrote:

 A short recap for those of you who are subscribed to freebsd-ports@
 but not freebsd-stable@: when I opened my inbox this morning I found
 a typical WTF thread: the (hardly) offensive fortune cookies have
 been kicked out of 10-BETA4. Since I (and many others) find this Just
 Plain Stupid (tm) I created a port to bring some sanity back into
 fortune(6).
 
 Anyone running FreeBSD 10-BETA4 feel free to test the port and
 comment on it before I file the PR asking for it to be committed.

I just tried. The port does not have any problems for me but fortune
seems to ignore FORTUNE_PATH.
 
 A shar patch can be found here:
 http://www.skysmurf.nl/comp/FreeBSD/files/ofortune.shar
 
 Or alternatively, a tarball can be found in the same place:
 http://www.skysmurf.nl/comp/FreeBSD/files/ofortune.tar.gz

I used this one.
 
 To extract the shar file:
 # cd /usr/ports/games
 # sh /path/to/shar-file
 
 Or alternatively, to extract the tarball:
 # cd /usr/ports/games
 # tar xzvf /path/to/tarball
 
 Install via your favourite method, e.g.
 
 # cd /usr/ports/games/ofortune
 # make install

I used the make method.

 or
 # portmaster games/ofortune
 
 PENDING ISSUES:
 
 -1-
 It's tentatively called ofortune. If you can think of a better name,
 then by all means shoot.
 
As already said, fortune-offensive sounds better.

 -2-
 The accompanying webpage is crap. This is no priority ;-)
 
I did not check it.

 -3-
 I have found the instructions for changing and/or adding to the
 fortune files but haven't tested them yet.
 
One step after another one.

 -4-
 I wanted to mark the port as IGNORE for versions of FreeBSD prior to
 10-BETA4. But this breaks stuff (see point 6) and I need to know
 exactly what the version number (OSVERSION) is for 10-BETA4.
 
 -5-
 Currently the port installs the offensive fortunes into
 /usr/local/share/ofortune, requiring every user to add that directory
 to their FORTUNE_PATH (hence the pkg-message). I tried adding an
 OPTION that would install it into the base /usr/share/games/fortune,
 but that again breaks stuff, see point 6.
 
 -6-
 It appears that for some reason conditionals don't work in the
 Makefile. For your reference, I have added the Makefile below, with
 the parts commented out that I think should work but don't. In both
 cases I get Malformed conditional errors. Any thoughts?

I use a very different style in my makefiles and do not see the errors
too.

Thanks for your work.

Erich
 
 Regards,
 
 AvW (fonz)
 
 [begin /usr/ports/games/ofortune/Makefile]
 # $FreeBSD$
 
 PORTNAME= ofortune
 PORTVERSION=  0.99.0
 CATEGORIES=   games
 MASTER_SITES= http://www.skysmurf.nl/comp/FreeBSD/distfiles/
 
 MAINTAINER=   free...@skysmurf.nl
 COMMENT=  The offensive fortune cookies that used to be in base.
 
 ###
 # This is supposed to work but doesn't.
 ###
 #OPTIONS_DEFINE=  BASE
 #OPTIONS_DEFAULT=
 #BASE_DESC=   To install into the base system rather
 than /usr/local. #
 #.include bsd.port.options.mk
 #
 #.if ${PORT_OPTIONS:BASE}
 #DATADIR= /usr/share/games/fortune
 #.else
 PLIST_DIRS=   ${DATADIR}
 #.endif
 
 PLIST_FILES=  ${DATADIR}/fortunes-o \
   ${DATADIR}/fortunes-o.dat \
   ${DATADIR}/murphy-o \
   ${DATADIR}/murphy-o.dat
 
 NO_BUILD= yes
 NO_INSTALL=   yes
 
 ###
 # This is supposed to work but doesn't.
 #
 # 702106 has been copied from an example, I need the right number for
 10-BETA4. #
 #.if ${OSVERSION}  702106
 #IGNORE=  For versions prior to 10-BETA4 this is still
 in base. #.endif
 ###
 
 post-install:
   ${MKDIR} ${STAGEDIR}${DATADIR}
   ${INSTALL_DATA} ${WRKSRC}/* ${STAGEDIR}${DATADIR}
 
 .include bsd.port.mk
 [end /usr/ports/games/ofortune/Makefile]
 

___
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: Output change of 'pkg info' after 1.2.

2013-12-05 Thread Lars Engels

Am 2013-12-05 17:54, schrieb Yasuhiro KIMURA:

From: Baptiste Daroussin b...@freebsd.org
Subject: Re: Output change of 'pkg info' after 1.2.
Date: Thu, 5 Dec 2013 17:24:09 +0100


On Thu, Dec 05, 2013 at 04:36:00PM +0100, Michael Gmelin wrote:

On Fri, 06 Dec 2013 00:13:38 +0900 (JST)
Yasuhiro KIMURA y...@utahime.org wrote:

 I noticed that output of 'pkg info' changed after version 1.2.

 If I remember correctly, 1.1.x behaved as following:

 - 'pkg info -q pkg-name' outputs package name with version.
 - 'pkg info pkg-name' outputs package name with version, and comment.
 - 'pkg info -f pkg-name' outputs full information.

 But 1.2.1 works as following:

 - 'pkg info -q pkg-name' outputs nothing.
 - Both 'pkg info pkg-name' and 'pkg info -f pkg-name' outputs full
   information.

Just tested, pkg 1.1.4 vs. 1.2.1

pkg info -q pkg-name is identical on both, but -f vs no parameter
definitely changed and this seems like a bug to me.



It is not a bug, but intended as requested by a lot of users. To mimic 
the

pkg_info behaviour.

pkg info -q shows nothing on purpose as well as pkg info -q is used by 
the
scripts like portmaster or by the ports tree and only the return value 
is

checked
0 means something was found 1 means nothing was found.


Thank you for explanation.

Then I have one question. Is there any way to get same output as
'pkg info pkg-name' of 1.1.x? I tried some combination of options but
could not find proper one.



1.1.4 doesn't behave like you describe, but here's a universal way:

root@fbsd01:~ # pkg info pkg
pkg-1.1.4_8

root@fbsd01:~ # pkg info icinga
icinga-1.9.3_2

root@fbsd01:~ # pkg query '%n-%v' icinga
icinga-1.9.3_2

root@fbsd01:~ # pkg query '%n-%v %c' icinga
icinga-1.9.3_2 Enterprise grade open source monitoring system based on 
Nagios


___
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