Re: Possible fix for Perl failing with ../lib/auto/POSIX/POSIX.so: Undefined symbol __flt_rounds on ARM

2012-06-12 Thread Jan Sieka 
On 2012.06.09 18:11, Tim Kientzle wrote:
 
 On Jun 5, 2012, at 8:09 AM, Jan Sieka wrote:
 
 Hello Ian!

 I tried recently to compile and run Perl 5.12 on ARM (SheevaPlug) using
 HEAD from 22.05.2012 and got the following error while trying to run:
 /usr/ports/lang/perl5.12 # make test
 [...]
 ../lib/auto/POSIX/POSIX.so: Undefined symbol __flt_rounds
 [...]

 After investigating the issue it appeared that __flt_rounds symbol is
 not exported by libc. Applying the following patch, recompilling world
 and Perl fixed the problem and allowed to use Perl on SheevaPlug:

 diff --git a/lib/libc/arm/Symbol.map b/lib/libc/arm/Symbol.map
 index e8c7f1d..8cdcdaf 100644
 --- a/lib/libc/arm/Symbol.map
 +++ b/lib/libc/arm/Symbol.map
 @@ -70,6 +70,7 @@ FBSDprivate_1.0 {
__divdf3;
__floatsisf;
__floatsidf;
 +   __flt_rounds;
__fixsfsi;
__fixdfsi;
__fixunssfsi;

 Can you comment whether this is a correct solution?
 
 Great!  I had the same problem compiling Python last
 week and had planned to track it down.
 
 I just committed this to -CURRENT and will also
 merge it to the armv6 tree.
Hello Tim!

Thanks for committing this but unfortunately that patch wasn't correct.
I had another discussion on freebsd-current@ (I forgot to do a
cross-list CC - now fixed) about how to add symbols to Symbols.map files
(see this thread:
http://lists.freebsd.org/pipermail/freebsd-current/2012-June/034511.html) and
from the answer and hints given by Konstantin Belousov I have prepared
another patch that adheres to library versioning guidelines. If nobody
objects this patch then feel free to commit it:

diff --git a/lib/libc/arm/Symbol.map b/lib/libc/arm/Symbol.map
index dc46013..48f6747 100644
--- a/lib/libc/arm/Symbol.map
+++ b/lib/libc/arm/Symbol.map
@@ -33,6 +33,10 @@ FBSD_1.0 {
sbrk;
 };

+FBSD_1.3 {
+   __flt_rounds;
+};
+
 FBSDprivate_1.0 {
/* PSEUDO syscalls */
__sys_getlogin;

I have verified the above patch is working on SheevaPlug on FreeBSD
10-CURRENT from 2012-05-15 and Perl 5.12.4. Perl has to be recompiled
after applying this patch.

Best regards,

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

Re: How to add symbol to be exported in lib/libc/arm/Symbol.map

2012-06-12 Thread Jan Sieka 
On 2012.06.08 19:04, Konstantin Belousov wrote:
 On Fri, Jun 08, 2012 at 02:51:09PM +0200, Jan Sieka wrote:
 Hello group!

 I have a few questions regarding adding symbols to
 lib/libc/arch/Symbol.map, so that function signatures are exported:
 - what are the conventions regarding putting symbols in FBSD_X.Y or
 FBSDprivate_X.Y sections of the aforementioned files?
 FBSD_X.Y are for public interfaces, i.e. non-system code is supposed to
 link to symbols from that versions. FBSDprivate is for exclusive base
 system use (so to say). We do not guarantee ABI stability for private.
 
 - when it is necessary to bump X.Y numbers?
 Currently, it is done when major branch is created.
 
 - what is the difference between FBSD_X.Y and FBSDprivate_X.Y sections?
 This is a repeat.
 

 The above questions arose from the discussion on freebsd-arm@
 (http://lists.freebsd.org/pipermail/freebsd-arm/2012-June/003555.html)
 which concerns fixing Perl on ARM. The fix is to add __flt_rounds
 function signature to lib/libc/arm/Symbols.map. Regarding this fix it
 appears (after Symbols.map files analysis and checking their SVN
 history) that adding this symbol is just a bug fix and should be put to
 FBSD_1.0 section without incrementing numbers. But I don't have more
 in-depth explanation so sending this email.
 No, since you are adding it in the CURRENT-10 timeframe, it goes
 to FBSD_1.3.
 

 Anyone can comment on the above questions or point to some documentation
 (I've searched Developer's Handbook and Internet but found nothing)?
 http://people.freebsd.org/~deischen/symver/freebsd_versioning.txt
 
 In fact, I do not like this policy, and would some day write a proposal,
 which essentially requests creation of separate version for each ABI change.
 But what is referenced is the current accepted project policy.
Thanks for response and hints. I have prepared patch according to the
above guidelines and sent it for comments in the aforementioned thread
on freebsd-arm@ (I also have CC-ed it to current@).

Best regards,

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

Re: Possible fix for Perl failing with ../lib/auto/POSIX/POSIX.so: Undefined symbol __flt_rounds on ARM

2012-06-12 Thread Jan Sieka 

On 2012.06.12 10:49, Konstantin Belousov wrote:

On Tue, Jun 12, 2012 at 10:18:58AM +0200, Jan Sieka wrote:

On 2012.06.09 18:11, Tim Kientzle wrote:


On Jun 5, 2012, at 8:09 AM, Jan Sieka wrote:


Hello Ian!

I tried recently to compile and run Perl 5.12 on ARM (SheevaPlug) using
HEAD from 22.05.2012 and got the following error while trying to run:
/usr/ports/lang/perl5.12 # make test
[...]
../lib/auto/POSIX/POSIX.so: Undefined symbol __flt_rounds
[...]

After investigating the issue it appeared that __flt_rounds symbol is
not exported by libc. Applying the following patch, recompilling world
and Perl fixed the problem and allowed to use Perl on SheevaPlug:

diff --git a/lib/libc/arm/Symbol.map b/lib/libc/arm/Symbol.map
index e8c7f1d..8cdcdaf 100644
--- a/lib/libc/arm/Symbol.map
+++ b/lib/libc/arm/Symbol.map
@@ -70,6 +70,7 @@ FBSDprivate_1.0 {
__divdf3;
__floatsisf;
__floatsidf;
+   __flt_rounds;
__fixsfsi;
__fixdfsi;
__fixunssfsi;

Can you comment whether this is a correct solution?


Great!  I had the same problem compiling Python last
week and had planned to track it down.

I just committed this to -CURRENT and will also
merge it to the armv6 tree.

Hello Tim!

Thanks for committing this but unfortunately that patch wasn't correct.
I had another discussion on freebsd-current@ (I forgot to do a
cross-list CC - now fixed) about how to add symbols to Symbols.map files
(see this thread:
http://lists.freebsd.org/pipermail/freebsd-current/2012-June/034511.html) and
from the answer and hints given by Konstantin Belousov I have prepared
another patch that adheres to library versioning guidelines. If nobody
objects this patch then feel free to commit it:

diff --git a/lib/libc/arm/Symbol.map b/lib/libc/arm/Symbol.map
index dc46013..48f6747 100644
--- a/lib/libc/arm/Symbol.map
+++ b/lib/libc/arm/Symbol.map
@@ -33,6 +33,10 @@ FBSD_1.0 {
 sbrk;
  };

+FBSD_1.3 {
+   __flt_rounds;
+};
+
  FBSDprivate_1.0 {
 /* PSEUDO syscalls */
 __sys_getlogin;

I have verified the above patch is working on SheevaPlug on FreeBSD
10-CURRENT from 2012-05-15 and Perl 5.12.4. Perl has to be recompiled
after applying this patch.

Well, both committed version and this version should work, the question
is which fix is right. Is __flt_rounds supposed to be linked to by
applications ? If the symbols are used by normal programs, that I think
we should indeed guarantee ABI stability for them, and FBSD_1.3
namespace is the right namespace to use.
Both versions work indeed. I have analysed other architectures' 
lib/libc/arch/Symbol.map files and __flt_rounds should go into FBSD_ and *not* 
into FBSDprivate section. I have verified that at least one of the Perl's 
libraries (POSIX.so) links to __flt_rounds. Python also links to this function. 
So to the best of my knowledge current patch is the righteous one.


Best regards,

Jan Sieka

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

How to add symbol to be exported in lib/libc/arm/Symbol.map

2012-06-08 Thread Jan Sieka 
Hello group!

I have a few questions regarding adding symbols to
lib/libc/arch/Symbol.map, so that function signatures are exported:
- what are the conventions regarding putting symbols in FBSD_X.Y or
FBSDprivate_X.Y sections of the aforementioned files?
- when it is necessary to bump X.Y numbers?
- what is the difference between FBSD_X.Y and FBSDprivate_X.Y sections?

The above questions arose from the discussion on freebsd-arm@
(http://lists.freebsd.org/pipermail/freebsd-arm/2012-June/003555.html)
which concerns fixing Perl on ARM. The fix is to add __flt_rounds
function signature to lib/libc/arm/Symbols.map. Regarding this fix it
appears (after Symbols.map files analysis and checking their SVN
history) that adding this symbol is just a bug fix and should be put to
FBSD_1.0 section without incrementing numbers. But I don't have more
in-depth explanation so sending this email.

Anyone can comment on the above questions or point to some documentation
(I've searched Developer's Handbook and Internet but found nothing)?

Regards,

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

Re: [workaroud/fix for] buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012

2012-04-27 Thread Jan Sieka 

On 2012.04.22 21:07, Garrett Cooper wrote:

On Apr 22, 2012, at 10:34 AM, Dimitry Andric wrote:


Well, I wouldn't want to run autoconf during build, firstly because it
is horribly slow, and second because the results will be less
predictable.  Maybe during the bootstrap stage, it would be acceptable.


Sure -- that seems reasonable.


But even then, one of the configure scripts could fail due to too-old
system components, and you would be SOL.


… but it would be a step forward from where things are currently at. I'm not sure how 
well tested source upgrade paths are, but being able to upgrade from the 
lowest supported version to the latest supported version, then upgrading to CURRENT (at 
the very least) would be nice.


Usually, if something is arch-dependent in a config.h file, we simply
surround it with #ifdefs.


Makes sense (assumption being that it can be controlled via the 
config.h/configure.{ac,in} file). However, jemalloc recently disproved this_.


Apparently the file(1) build needs a 'mkmagic' tool, which generates
.mgc files (the 'compiled' version of magic files).  This requirement
was originally added in r81845, more than 10 years ago.


I tested out removing libmagic from Makefile.inc1 and see that there's some 
dependency magic going on there where building the library failed.


Yes, it might work, but there is no guarantee.  I'm not sure if there is
enough incentive to change this policy.  It would potentially require a
lot effort to make it always work.


Understood and I guess the ownness is upon the stakeholders to fix this, but 
there are a lot of companies that depend on things like this working (at least 
to reduce pain when doing source upgrades). This would probably be less of an 
issue for developers that use freebsd-update or for companies that roll their 
own freebsd-update (and servers). I have yet to run into a company that does 
this though (not saying there aren't groups that could or do do this, but it's 
not the standard path).


I wasn't aware of any chroot hackery?


A publicly available example is available in FreeNAS ( 
http://freenas.svn.sourceforge.net/viewvc/freenas?view=revisionrevision=8193 
); the hangup is building packages for a target system that doesn't match the build 
host.

Cheers!
-Garrett

Hello!

I have prepared workaround/fix for this issue. It has been tested on FreeBSD 7.3 
and 9.0 (both RELEASE) with good results: world build finishes OK. I attach the 
patch in case someone else is hit by this issue. Feel free to use it.


Thanks for all suggestions and comments.

Regards,

Jan Sieka

diff --git a/lib/libmagic/Makefile b/lib/libmagic/Makefile
index 9c35c35..e9b8240 100644
--- a/lib/libmagic/Makefile
+++ b/lib/libmagic/Makefile
@@ -10,9 +10,16 @@ DPADD=   ${LIBZ}
 LDADD= -lz
 MAN=   libmagic.3 magic.5
 
+HOSTOSRELDATE!=echo ${VERSION} | cut -d   -f 4
+
+.if ${HOSTOSRELDATE}  80
+GETLINE_C= getline.c
+.else
+GETLINE_C=
+.endif
 SRCS=  apprentice.c apptype.c ascmagic.c cdf.c cdf_time.c compress.c \
encoding.c fsmagic.c funcs.c \
-   is_tar.c magic.c print.c readcdf.c readelf.c softmagic.c
+   is_tar.c magic.c print.c readcdf.c readelf.c softmagic.c ${GETLINE_C}
 INCS=  magic.h
 
 MAGICPATH?=/usr/share/misc
@@ -39,7 +46,8 @@ magic.mgc: mkmagic magic
 
 CLEANFILES+=   mkmagic
 build-tools: mkmagic
-mkmagic: apprentice.c funcs.c magic.c print.c
+
+mkmagic: apprentice.c funcs.c magic.c print.c ${GETLINE_C}
${CC} ${CFLAGS} -DCOMPILE_ONLY ${LDFLAGS} -o ${.TARGET} ${.ALLSRC}
 
 FILEVER!= awk '$$1 == \#define  $$2 == VERSION { print $$3; exit }' \
diff --git a/lib/libmagic/config.h b/lib/libmagic/config.h
index 06ed4ec..3fe103e 100644
--- a/lib/libmagic/config.h
+++ b/lib/libmagic/config.h
@@ -39,7 +39,11 @@
 #define HAVE_FSEEKO 1
 
 /* Define to 1 if you have the `getline' function. */
-#define HAVE_GETLINE 1
+#if (__FreeBSD_version = 80)
+#defineHAVE_GETLINE 1
+#else
+#defineHAVE_GETLINE 0
+#endif
 
 /* Define to 1 if you have the getopt.h header file. */
 #define HAVE_GETOPT_H 1
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012

2012-04-20 Thread Jan Sieka 

Hello!

I can't build world from recent sources (HEAD as of 2012.04.19 11:06:48 UTC) on 
a machine running FreeBSD 7.3. I know it's EoLed, but I have found information 
in getline(3) manual that this function first appeared in FreeBSD 8, so I 
presume that the problem is present also for FreeBSD 7.4 (which is still before 
EoL). I have confirmed that problem doesn't exists for FreeBSD 9.0.


Here's excerpt from build log:

=== lib/libmagic (obj,build-tools)
cc -O2 -pipe -DMAGIC='/usr/share/misc/magic' -DHAVE_CONFIG_H
-I/usr/src/current/lib/libmagic
-I/usr/src/current/lib/libmagic/../../contrib/file
-std=gnu99
-I/usr/obj/usr/src/current/tmp/legacy/usr/include
-DCOMPILE_ONLY
-L/usr/obj/usr/src/current/tmp/legacy/usr/lib
-o mkmagic
/usr/src/current/lib/libmagic/../../contrib/file/apprentice.c
/usr/src/current/lib/libmagic/../../contrib/file/funcs.c
/usr/src/current/lib/libmagic/../../contrib/file/magic.c
/usr/src/current/lib/libmagic/../../contrib/file/print.c
/usr/src/current/lib/libmagic/../../contrib/file/apprentice.c:
In function 'load_1':
/usr/src/current/lib/libmagic/../../contrib/file/apprentice.c:701:
warning: implicit declaration of function 'getline'
/var/tmp//cc7NqjVu.o(.text+0x699): In function `load_1':
: undefined reference to `getline'
*** Error code 1

Stop in /usr/src/current/lib/libmagic.
*** Error code 1

Stop in /usr/src/current.
*** Error code 1

Stop in /usr/src/current.
*** Error code 1

Stop in /usr/src/current.


Regards,

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