build issues on rhel5/centos5 and sl5 (any rhel5 like distro really)

515 views
Skip to first unread message

Jimmy

unread,
May 4, 2010, 4:42:59 AM5/4/10
to The X Binary Package System
Hi,

[jtang@duo xbps]$ make
make[1]: Entering directory `/home/jtang/xbps/include'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/jtang/xbps/include'
make[1]: Entering directory `/home/jtang/xbps/lib'
[CC] configure.o
[CC] config_files.o
[CC] cmpver.o
[CC] download.o
[CC] fexec.o
[CC] humanize_number.o
[CC] orphans.o
[CC] plist.o
[CC] purge.o
[CC] register.o
[CC] regpkgs_dictionary.o
[CC] remove.o
[CC] remove_obsoletes.o
[CC] repository.o
[CC] repository_finddeps.o
[CC] repository_findpkg.o
[CC] repository_plist.o
[CC] repository_pool.o
[CC] repository_sync_index.o
[CC] requiredby.o
[CC] sha256.o
cc1: warnings being treated as errors
sha256.c: In function 'SHA256_Transform':
sha256.c:249: warning: implicit declaration of function 'be32toh'
sha256.c: In function 'SHA224_256_Final':
sha256.c:378: warning: implicit declaration of function 'htobe64'
sha256.c:418: warning: implicit declaration of function 'htobe32'
make[1]: *** [sha256.o] Error 1
make[1]: Leaving directory `/home/jtang/xbps/lib'
make: *** [all] Error 1
[jtang@duo xbps]$

rhel5 and friends dont have the macros to do all the byteswapping. i
guess you can't assuming all linux's are the same

jimmy

--
XBPS - The X Binary Package System

You received this message because you are subscribed to the Google
Groups "xbps" group.
To post to this group, send email to xb...@googlegroups.com
To unsubscribe from this group, send email to
xbps+uns...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/xbps?hl=en

Juan Romero Pardines

unread,
May 4, 2010, 6:21:55 AM5/4/10
to xb...@googlegroups.com
2010/5/4 Jimmy <jcf...@gmail.com>:
Thanks for the report, Jimmy.

I'm sorry, where does rhel5 have the byte swapping macros?

Jimmy Tang

unread,
May 4, 2010, 6:57:42 AM5/4/10
to xb...@googlegroups.com
Hi Juan,
I think on rhel5 the macros for the be*toh macros is bswap_* and for
the htobe* macros, the closest thing i can see is the htno*/nto*
macros, at least thats what i can see from the byteorder man pages.



jimmy

Juan Romero Pardines

unread,
May 4, 2010, 7:10:37 AM5/4/10
to xb...@googlegroups.com
2010/5/4 Jimmy Tang <jcf...@gmail.com>:

> I think on rhel5 the macros for the be*toh macros is  bswap_* and for
> the htobe* macros, the closest thing i can see is the htno*/nto*
> macros, at least thats what i can see from the  byteorder  man pages.

Could you please send me the header or guide me online where they are
defined? We can set
some defines if standard ones aren't found to the ones that this
header contains.

Juan Romero Pardines

unread,
May 4, 2010, 7:59:30 AM5/4/10
to xb...@googlegroups.com
2010/5/4 Juan Romero Pardines <xtr...@gmail.com>:
> 2010/5/4 Jimmy Tang <jcf...@gmail.com>:
>
>> I think on rhel5 the macros for the be*toh macros is  bswap_* and for
>> the htobe* macros, the closest thing i can see is the htno*/nto*
>> macros, at least thats what i can see from the  byteorder  man pages.
>
> Could you please send me the header or guide me online where they are
> defined? We can set
> some defines if standard ones aren't found to the ones that this
> header contains.

Ok, now I understand. The htobe* and other macros used in sha256.c are defined
in endian.h on Glibc and sys/endian.h on the BSDs, but they are non standard.

I'll prepare a patch in a few minutes for you to test.

Jimmy Tang

unread,
May 4, 2010, 8:03:29 AM5/4/10
to xb...@googlegroups.com
On Tue, May 4, 2010 at 12:59 PM, Juan Romero Pardines <xtr...@gmail.com> wrote:
> 2010/5/4 Juan Romero Pardines <xtr...@gmail.com>:
>> 2010/5/4 Jimmy Tang <jcf...@gmail.com>:
>>
>>> I think on rhel5 the macros for the be*toh macros is  bswap_* and for
>>> the htobe* macros, the closest thing i can see is the htno*/nto*
>>> macros, at least thats what i can see from the  byteorder  man pages.
>>
>> Could you please send me the header or guide me online where they are
>> defined? We can set
>> some defines if standard ones aren't found to the ones that this
>> header contains.
>
> Ok, now I understand. The htobe* and other macros used in sha256.c are defined
> in endian.h on Glibc and sys/endian.h on the BSDs, but they are non standard.
>
> I'll prepare a patch in a few minutes for you to test.
>

cool, thanks. i will do a test build as soon as you upload the changes..


jimmy.

Juan Romero Pardines

unread,
May 4, 2010, 8:15:12 AM5/4/10
to xb...@googlegroups.com
2010/5/4 Jimmy Tang <jcf...@gmail.com>:

> cool, thanks. i will do a test build as soon as you upload the changes..

Ok, let's see if this patch works:

---- CUT HERE ----
--- a/lib/sha256.c Mon May 03 22:01:18 2010 +0200
+++ b/lib/sha256.c Tue May 04 14:14:22 2010 +0200
@@ -36,6 +36,7 @@
*
*/

+#include <sys/param.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <errno.h>
@@ -51,6 +52,34 @@
#include <xbps_api.h>
#include "sha256.h"

+/* Workaround byte swap cludge on Linux systems */
+#ifdef _BSD
+#include <sys/endian.h>
+#elif defined(__linux__)
+#include <byteswap.h>
+# if __BYTE_ORDER == __LITTLE_ENDIAN
+# ifndef htobe32
+# define htobe32(x) bswap_32 (x)
+# endif
+# ifndef be32toh
+# define be32toh(x) bswap_32 (x)
+# endif
+# ifndef htobe64
+# define htobe64(x) bswap_64 (x)
+# endif
+# else
+# ifndef htobe32
+# define htobe32(x) (x)
+# endif
+# ifndef be32toh
+# define be32toh(x) (x)
+# endif
+# ifndef htobe64
+# define htobe64(x) (x)
+# endif
+# endif
+#endif
+
/*** SHA-256 Various Length Definitions ***********************/
/* NOTE: Most of these are in sha2.h */
#define SHA256_SHORT_BLOCK_LENGTH (SHA256_BLOCK_LENGTH - 8)
---- CUT HERE ----

Jimmy Tang

unread,
May 4, 2010, 8:33:43 AM5/4/10
to xb...@googlegroups.com
Hi Juan,

On Tue, May 4, 2010 at 1:15 PM, Juan Romero Pardines <xtr...@gmail.com> wrote:
> 2010/5/4 Jimmy Tang <jcf...@gmail.com>:
>
>> cool, thanks. i will do a test build as soon as you upload the changes..
>
> Ok, let's see if this patch works:
>

I just tested the patch, the build now compiles all the object files
but fails to link, it looks like that its just linux (rhel like
distros) just suck when it comes to linking...

[jtang@duo xbps]$ make
make[1]: Entering directory `/home/jtang/xbps/include'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/jtang/xbps/include'
make[1]: Entering directory `/home/jtang/xbps/lib'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/jtang/xbps/lib'
make[1]: Entering directory `/home/jtang/xbps/bin'
make[2]: Entering directory `/home/jtang/xbps/bin/xbps-uhelper'
[CCLD] xbps-uhelper
../../lib/libxbps.so: undefined reference to `pthread_rwlock_rdlock'
../../lib/libxbps.so: undefined reference to `pthread_rwlock_wrlock'
../../lib/libxbps.so: undefined reference to `pthread_rwlock_destroy'
../../lib/libxbps.so: undefined reference to `pthread_rwlock_init'
../../lib/libxbps.so: undefined reference to `pthread_rwlock_unlock'
collect2: ld returned 1 exit status
make[2]: *** [xbps-uhelper] Error 1
make[2]: Leaving directory `/home/jtang/xbps/bin/xbps-uhelper'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/jtang/xbps/bin'
make: *** [all] Error 1

I'll play around with this to see if i can get it to link.


thanks,
jimmy.

Juan Romero Pardines

unread,
May 4, 2010, 8:39:05 AM5/4/10
to xb...@googlegroups.com
2010/5/4 Jimmy Tang <jcf...@gmail.com>:

> I just tested the patch, the build now compiles all the object files
> but fails to link, it looks like that its just linux (rhel like
> distros) just suck when it comes to linking...

Thanks I committed the patch.

> [jtang@duo xbps]$ make
> make[1]: Entering directory `/home/jtang/xbps/include'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory `/home/jtang/xbps/include'
> make[1]: Entering directory `/home/jtang/xbps/lib'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory `/home/jtang/xbps/lib'
> make[1]: Entering directory `/home/jtang/xbps/bin'
> make[2]: Entering directory `/home/jtang/xbps/bin/xbps-uhelper'
>  [CCLD]         xbps-uhelper
> ../../lib/libxbps.so: undefined reference to `pthread_rwlock_rdlock'
> ../../lib/libxbps.so: undefined reference to `pthread_rwlock_wrlock'
> ../../lib/libxbps.so: undefined reference to `pthread_rwlock_destroy'
> ../../lib/libxbps.so: undefined reference to `pthread_rwlock_init'
> ../../lib/libxbps.so: undefined reference to `pthread_rwlock_unlock'
> collect2: ld returned 1 exit status
> make[2]: *** [xbps-uhelper] Error 1
> make[2]: Leaving directory `/home/jtang/xbps/bin/xbps-uhelper'
> make[1]: *** [all] Error 1
> make[1]: Leaving directory `/home/jtang/xbps/bin'
> make: *** [all] Error 1
>
> I'll play around with this to see if i can get it to link.

Ah probably my fault. Please add into lib/Makefile:

LDFLAGS += -lpthread

Jimmy Tang

unread,
May 4, 2010, 8:51:51 AM5/4/10
to xb...@googlegroups.com
>>
>> I'll play around with this to see if i can get it to link.
>
> Ah probably my fault. Please add into lib/Makefile:
>
> LDFLAGS += -lpthread
>


done, it dynamically links now, static linking still fails

i just did this...

LDFLAGS += -larchive -lssl -lz -lpthread

fails with...

[jtang@duo xbps]$ make
make[1]: Entering directory `/home/jtang/xbps/include'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/jtang/xbps/include'
make[1]: Entering directory `/home/jtang/xbps/lib'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/jtang/xbps/lib'
make[1]: Entering directory `/home/jtang/xbps/bin'
make[2]: Entering directory `/home/jtang/xbps/bin/xbps-uhelper'
[CCLD] xbps-uhelper.static
make[2]: *** [xbps-uhelper.static] Error 1
make[2]: Leaving directory `/home/jtang/xbps/bin/xbps-uhelper'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/jtang/xbps/bin'
make: *** [all] Error 1
[jtang@duo xbps]$



jimmy

Juan Romero Pardines

unread,
May 4, 2010, 8:56:23 AM5/4/10
to xb...@googlegroups.com
2010/5/4 Jimmy Tang <jcf...@gmail.com>:

> done, it dynamically links now, static linking still fails
>
> i just did this...
>
> LDFLAGS += -larchive -lssl -lz -lpthread
>
> fails with...

Do you have pkgconfig and libarchive >= 2.8.0? make sure that you have
libarchive.pc and openssl.pc.

You also need static libs for zlib, libpthread, openssl and libarchive.

Please remove the part "> /dev/null 2>&1" from prog.mk here:

$(BIN).static: $(OBJS)
@printf " [CCLD]\t\t$@\n"
@$(CC) -static $^ $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) \
$(STATIC_LIBS) -o $@ >/dev/null 2>&1

Juan Romero Pardines

unread,
May 4, 2010, 9:04:45 AM5/4/10
to xb...@googlegroups.com
2010/5/4 Juan Romero Pardines <xtr...@gmail.com>:
> 2010/5/4 Jimmy Tang <jcf...@gmail.com>:
>
>> done, it dynamically links now, static linking still fails
>>
>> i just did this...
>>
>> LDFLAGS += -larchive -lssl -lz -lpthread
>>
>> fails with...
>
> Do you have pkgconfig and libarchive >= 2.8.0? make sure that you have
> libarchive.pc and openssl.pc.
>
> You also need static libs for zlib, libpthread, openssl and libarchive.
>
> Please remove the part "> /dev/null 2>&1" from prog.mk here:
>
> $(BIN).static: $(OBJS)
>        @printf " [CCLD]\t\t$@\n"
>        @$(CC) -static $^ $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) \
>                $(STATIC_LIBS) -o $@ >/dev/null 2>&1
>

I committed this part:

changeset: 304:d5ef997c5c8f
tag: tip
user: Juan RP <xtr...@gmail.com>
date: Tue May 04 15:04:06 2010 +0200
files: prog.mk
description:
prog.mk: don't redirect stderr to /dev/null for static linking.

It's useful to see some possible errors.

Jimmy Tang

unread,
May 4, 2010, 9:30:50 AM5/4/10
to xb...@googlegroups.com
On Tue, May 4, 2010 at 2:04 PM, Juan Romero Pardines <xtr...@gmail.com> wrote:
> 2010/5/4 Juan Romero Pardines <xtr...@gmail.com>:
>> 2010/5/4 Jimmy Tang <jcf...@gmail.com>:
>>
>>> done, it dynamically links now, static linking still fails
>>>
>>> i just did this...
>>>
>>> LDFLAGS += -larchive -lssl -lz -lpthread
>>>
>>> fails with...
>>
>> Do you have pkgconfig and libarchive >= 2.8.0? make sure that you have
>> libarchive.pc and openssl.pc.
>>

yeap all that is there, i made sure of it, it seems like the rhel5 ssl
libraries depend on kerberos5 (kr5b development libraries)

[jtang@duo xbps]$ make
make[1]: Entering directory `/home/jtang/xbps/include'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/jtang/xbps/include'
make[1]: Entering directory `/home/jtang/xbps/lib'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/jtang/xbps/lib'
make[1]: Entering directory `/home/jtang/xbps/bin'
make[2]: Entering directory `/home/jtang/xbps/bin/xbps-uhelper'
[CCLD] xbps-uhelper.static
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libcrypto.a(fips.o):
In function `FIPSCHECK_verify':
(.text+0x7fa): warning: Using 'dlopen' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
../../lib/libxbps.a(common.o): In function `fetch_netrc_auth':
common.c:(.text+0x209d): warning: Using 'getpwuid' in statically
linked applications requires at runtime the shared libraries from the
glibc version used for linking
../../lib/libxbps.a(common.o): In function `fetch_bind':
common.c:(.text+0x54d): warning: Using 'getaddrinfo' in statically
linked applications requires at runtime the shared libraries from the
glibc version used for linking
../../lib/libxbps.a(common.o): In function `fetch_default_port':
common.c:(.text+0x36a): warning: Using 'getservbyname' in statically
linked applications requires at runtime the shared libraries from the
glibc version used for linking
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libssl.a(kssl.o):
In function `get_rc_clockskew':
(.text+0xbe): undefined reference to `krb5_rc_default'
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libssl.a(kssl.o):
In function `get_rc_clockskew':
(.text+0xd0): undefined reference to `krb5_rc_initialize'
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libssl.a(kssl.o):
In function `get_rc_clockskew':
(.text+0xf0): undefined reference to `krb5_rc_get_lifespan'


i think its just a case of figuring out the dependancies and
installing them and giving vars.mk the correct static_libs flags

jimmy

Juan Romero Pardines

unread,
May 4, 2010, 9:33:28 AM5/4/10
to xb...@googlegroups.com
2010/5/4 Jimmy Tang <jcf...@gmail.com>:

> yeap all that is there, i made sure of it, it seems like the rhel5 ssl
> libraries depend on kerberos5 (kr5b development libraries)

Ugh! that's why I switched to pkg-config.
Can you show the output for the command "pkg-config openssl --libs --static" ?

In that case probably you also need the krb5 static libs.

Jimmy Tang

unread,
May 4, 2010, 9:40:20 AM5/4/10
to xb...@googlegroups.com
On Tue, May 4, 2010 at 2:33 PM, Juan Romero Pardines <xtr...@gmail.com> wrote:
> 2010/5/4 Jimmy Tang <jcf...@gmail.com>:
>
>> yeap all that is there, i made sure of it, it seems like the rhel5 ssl
>> libraries depend on kerberos5 (kr5b development libraries)
>
> Ugh! that's why I switched to pkg-config.
>

[jtang@duo xbps]$ pkg-config openssl --libs --static
-L/usr/kerberos/lib64 -lssl -lcrypto -ldl -lz

this is pretty distro specific :P static linking on linux is never fun.


jimmy

Juan Romero Pardines

unread,
May 4, 2010, 9:44:52 AM5/4/10
to xb...@googlegroups.com
2010/5/4 Jimmy Tang <jcf...@gmail.com>:

> [jtang@duo xbps]$ pkg-config openssl --libs --static
> -L/usr/kerberos/lib64 -lssl -lcrypto -ldl -lz
>
> this is pretty distro specific :P static linking on linux is never fun.

That's the problem, it uses -L/path/to/krb5/libdir but doesn't link to
the krb5 library!

I'd call this a bug in the RHEL5 openssl package, anyway to workaround
it you could
use something like the following in vars.mk:

# Grr, hate the static libs!
STATIC_LIBS = -lz $(STATIC_PROPLIB) -lpthread
STATIC_LIBS += -lkrb5 `pkg-config openssl --libs --static`
STATIC_LIBS += `pkg-config libarchive --libs --static`

Please note that the problem resides in your distro's provided
openssl.pc file and not
in the XBPS build infrastructure. If pkg-config doesn't list all
required dependent
libraries there is not much we can do...

Juan Romero Pardines

unread,
May 4, 2010, 9:56:08 AM5/4/10
to xb...@googlegroups.com
2010/5/4 Juan Romero Pardines <xtr...@gmail.com>:

> # Grr, hate the static libs!
> STATIC_LIBS =   -lz $(STATIC_PROPLIB) -lpthread
> STATIC_LIBS +=  -lkrb5 `pkg-config openssl --libs --static`
> STATIC_LIBS +=  `pkg-config libarchive --libs --static`

Better even, use `krb5-config --libs` rather than -lkrb5.

Juan Romero Pardines

unread,
May 4, 2010, 10:15:45 AM5/4/10
to xb...@googlegroups.com
2010/5/4 Juan Romero Pardines <xtr...@gmail.com>:
> 2010/5/4 Juan Romero Pardines <xtr...@gmail.com>:
>
>> # Grr, hate the static libs!
>> STATIC_LIBS =   -lz $(STATIC_PROPLIB) -lpthread
>> STATIC_LIBS +=  -lkrb5 `pkg-config openssl --libs --static`
>> STATIC_LIBS +=  `pkg-config libarchive --libs --static`

As last workaround you can use the static binaries I provide in the official
repository here:

http://xbps.nopcode.org/repos/stable/x86_64/xbps-static-0.5.0.x86_64.xbps

You can unpack it with tar+xz or bsdtar+xz. These binary pkgs are xz compressed
tarballs, so you can use 'tar tvfJ" to see its contents. To play with
xbps-src you
only need the .static binaries.

Jimmy Tang

unread,
May 4, 2010, 10:22:05 AM5/4/10
to xb...@googlegroups.com
i'm most of the way there,

STATIC_LIBS += `krb5-config --libs krb5` -lkrb5support -lselinux
-lkeyutils -lresolv -lsepol



[jtang@duo xbps]$ make
make[1]: Entering directory `/home/jtang/xbps/include'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/jtang/xbps/include'
make[1]: Entering directory `/home/jtang/xbps/lib'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/jtang/xbps/lib'
make[1]: Entering directory `/home/jtang/xbps/bin'
make[2]: Entering directory `/home/jtang/xbps/bin/xbps-uhelper'
[CCLD] xbps-uhelper.static
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libcrypto.a(fips.o):
In function `FIPSCHECK_verify':
(.text+0x7fa): warning: Using 'dlopen' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
../../lib/libxbps.a(common.o): In function `fetch_netrc_auth':
common.c:(.text+0x209d): warning: Using 'getpwuid' in statically
linked applications requires at runtime the shared libraries from the
glibc version used for linking
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libkrb5.a(prof_file.o):
In function `profile_open_file':
(.text+0x2a0f): warning: Using 'getpwuid_r' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
../../lib/libxbps.a(common.o): In function `fetch_bind':
common.c:(.text+0x54d): warning: Using 'getaddrinfo' in statically
linked applications requires at runtime the shared libraries from the
glibc version used for linking
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libkrb5support.a(fake-addrinfo.o):
In function `krb5int_getaddrinfo':
(.text+0xd6): warning: Using 'gethostbyname_r' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
../../lib/libxbps.a(common.o): In function `fetch_default_port':
common.c:(.text+0x36a): warning: Using 'getservbyname' in statically
linked applications requires at runtime the shared libraries from the
glibc version used for linking
../../lib/libxbps.a(plist.o): In function `xbps_read_dict_from_archive_entry':
plist.c:(.text+0xc46): undefined reference to `archive_entry_size'
plist.c:(.text+0xc7c): undefined reference to `archive_read_data'
collect2: ld returned 1 exit status
make[2]: *** [xbps-uhelper.static] Error 1
make[2]: Leaving directory `/home/jtang/xbps/bin/xbps-uhelper'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/jtang/xbps/bin'
make: *** [all] Error 1
[jtang@duo xbps]$

Juan Romero Pardines

unread,
May 4, 2010, 10:27:35 AM5/4/10
to xb...@googlegroups.com
2010/5/4 Jimmy Tang <jcf...@gmail.com>:

> ../../lib/libxbps.a(plist.o): In function `xbps_read_dict_from_archive_entry':
> plist.c:(.text+0xc46): undefined reference to `archive_entry_size'
> plist.c:(.text+0xc7c): undefined reference to `archive_read_data'
> collect2: ld returned 1 exit status

Probably this is due to incorrect order of static libs. That is the worst part
of static linking! you really have to use the correct order and it sucks.

Jimmy Tang

unread,
May 4, 2010, 10:31:59 AM5/4/10
to xb...@googlegroups.com
actually, this works, just add this to the end of the vars.mk file

STATIC_LIBS += `krb5-config --libs krb5` -lkrb5support -lselinux
-lkeyutils -lresolv -lsepol -larchive -lbz2 -lacl

you will need to have at least this... installed from the rpm repos
that rhel ship...


openssl-devel
krb5-devel
keyutils-libs-devel
libsepol-devel
libselinux-devel

i install libarchive from source. it all seemed to link and the
binaries run. i will test them later on this evening to mess around
with it. thanks for the help in getting it to at least compile and
link ;)


jimmy

Juan Romero Pardines

unread,
May 4, 2010, 10:33:36 AM5/4/10
to xb...@googlegroups.com
2010/5/4 Jimmy Tang <jcf...@gmail.com>:

> actually, this works, just add this to the end of the vars.mk file
>
> STATIC_LIBS +=  `krb5-config --libs krb5` -lkrb5support -lselinux
> -lkeyutils -lresolv -lsepol -larchive -lbz2 -lacl
>
> you will need to have at least this... installed from the rpm repos
> that rhel ship...
>
>
> openssl-devel
> krb5-devel
> keyutils-libs-devel
> libsepol-devel
> libselinux-devel
>
> i install libarchive from source. it all seemed to link and the
> binaries run. i will test them later on this evening to mess around
> with it. thanks for the help in getting it to at least compile and
> link ;)

Cool! perhaps I can add this to the wiki for future users.

Thanks for your contribution.

Juan Romero Pardines

unread,
May 4, 2010, 10:42:48 AM5/4/10
to xb...@googlegroups.com
2010/5/4 Juan Romero Pardines <xtr...@gmail.com>:

> Cool! perhaps I can add this to the wiki for future users.

I added your notes here:

http://code.google.com/p/xbps/wiki/HowtoBuildXBPSUtils

Thanks!

Jimmy Tang

unread,
May 4, 2010, 11:10:56 AM5/4/10
to xb...@googlegroups.com
On Tue, May 4, 2010 at 3:42 PM, Juan Romero Pardines <xtr...@gmail.com> wrote:
> 2010/5/4 Juan Romero Pardines <xtr...@gmail.com>:
>
>> Cool! perhaps I can add this to the wiki for future users.
>
> I added your notes here:
>
> http://code.google.com/p/xbps/wiki/HowtoBuildXBPSUtils
>
> Thanks!
>


sure, i will test abit more this evening with a fresh checkout and on
a different machine to make sure the notes are correct.

thanks,
jimmy

Juan Romero Pardines

unread,
May 4, 2010, 11:22:54 AM5/4/10
to xb...@googlegroups.com
2010/5/4 Jimmy Tang <jcf...@gmail.com>:

> sure, i will test abit more this evening with a fresh checkout and on
> a different machine to make sure the notes are correct.

Ok, make sure that you use sources from master mercurial repo:

$ hg clone http://xbps.googlecode.com/hg

Cheers!
Reply all
Reply to author
Forward
0 new messages