Discussion:
[OpenRISC] Building uClibc-or1k failed: storage size unknown
Ziqiang Patrick Huang
2015-01-19 17:29:57 UTC
Permalink
Hi I'm trying to build uClibc toolchain by following the instructions on
http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Linux_.28uClibc.29_toolchain_.28or1k-linux-uclibc.29

When building uClibc-or1k, I got stuck at the error\

libc/sysdeps/linux/common/fstat.c:48:21: error: storage size of 'kbuf'
isn't known
struct kernel_stat kbuf;

Anyone had the same problem before ?

Thanks,
Patrick
Ziqiang Patrick Huang
2015-01-19 20:07:22 UTC
Permalink
After commenting out the following line in the Makefile.in, the above error
goes away

ifneq ($(ARCH_HAS_DEPRECATED_SYSCALLS),y)



$(ALL_HEADERS_BITS_COMMON_NO_LEGACY):



$(do_ln) $(call
rel_srcdir)libc/sysdeps/linux/common-generic/bits/$(@F) $@


endif

But it got stuck again at

libc/sysdeps/linux/common/posix_fadvise.c:52:28: error: conflicting types
for 'posix_fadvise64'
strong_alias(posix_fadvise,posix_fadvise64)
^
./include/libc-symbols.h:190:26: note: in definition of macro
'_strong_alias'
extern __typeof (name) aliasname __attribute__ ((alias (#name)));
^
libc/sysdeps/linux/common/posix_fadvise.c:52:1: note: in expansion of macro
'strong_alias'
strong_alias(posix_fadvise,posix_fadvise64)
^
In file included from libc/sysdeps/linux/common/posix_fadvise.c:21:0:
./include/fcntl.h:214:12: note: previous declaration of 'posix_fadvise64'
was here
extern int posix_fadvise64 (int __fd, __off64_t __offset, __off64_t __len,
^
make: *** [libc/sysdeps/linux/common/posix_fadvise.os] Error 1


Any help is much appreciated.


2015-01-19 12:29 GMT-05:00 Ziqiang Patrick Huang <
Post by Ziqiang Patrick Huang
Hi I'm trying to build uClibc toolchain by following the instructions on
http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Linux_.28uClibc.29_toolchain_.28or1k-linux-uclibc.29
When building uClibc-or1k, I got stuck at the error\
libc/sysdeps/linux/common/fstat.c:48:21: error: storage size of 'kbuf'
isn't known
struct kernel_stat kbuf;
Anyone had the same problem before ?
Thanks,
Patrick
--
*Ziqiang Huang*
*Electrical and Computer Engineering*
*Hudson 213c, Duke University*
*Tel: 919-491-3677*
*Email: ***@duke.edu <***@duke.edu>*
Stefan Kristiansson
2015-01-19 22:39:19 UTC
Permalink
On Mon, Jan 19, 2015 at 7:29 PM, Ziqiang Patrick Huang <
Post by Ziqiang Patrick Huang
Hi I'm trying to build uClibc toolchain by following the instructions on
http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Linux_.28uClibc.29_toolchain_.28or1k-linux-uclibc.29
When building uClibc-or1k, I got stuck at the error\
libc/sysdeps/linux/common/fstat.c:48:21: error: storage size of 'kbuf'
isn't known
struct kernel_stat kbuf;
Anyone had the same problem before ?
I bet you are using the wrong kernel headers, the instructions says to use
the headers from upstream, did you do that?
Ziqiang Patrick Huang
2015-01-20 01:23:42 UTC
Permalink
Stefan,

Thanks for your reply, I did use the headers from upstream from
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

I solved this problem by commenting some commands out in uclibc makefile.


Right now I'm stuck at the below error

libc/sysdeps/linux/common/posix_fadvise.c:52:28: error: conflicting types
for 'posix_fadvise64'
strong_alias(posix_fadvise,posix_fadvise64)
^
./include/libc-symbols.h:190:26: note: in definition of macro
'_strong_alias'
extern __typeof (name) aliasname __attribute__ ((alias (#name)));
^
libc/sysdeps/linux/common/posix_fadvise.c:52:1: note: in expansion of macro
'strong_alias'
strong_alias(posix_fadvise,posix_fadvise64)
^
In file included from libc/sysdeps/linux/common/posix_fadvise.c:21:0:
./include/fcntl.h:214:12: note: previous declaration of 'posix_fadvise64'
was here
extern int posix_fadvise64 (int __fd, __off64_t __offset, __off64_t __len,
^
make: *** [libc/sysdeps/linux/common/posix_fadvise.os] Error 1

2015-01-19 17:39 GMT-05:00 Stefan Kristiansson <
Post by Stefan Kristiansson
On Mon, Jan 19, 2015 at 7:29 PM, Ziqiang Patrick Huang <
Post by Ziqiang Patrick Huang
Hi I'm trying to build uClibc toolchain by following the instructions on
http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Linux_.28uClibc.29_toolchain_.28or1k-linux-uclibc.29
When building uClibc-or1k, I got stuck at the error\
libc/sysdeps/linux/common/fstat.c:48:21: error: storage size of 'kbuf'
isn't known
struct kernel_stat kbuf;
Anyone had the same problem before ?
I bet you are using the wrong kernel headers, the instructions says to use
the headers from upstream, did you do that?
--
*Ziqiang Huang*
*Electrical and Computer Engineering*
*Hudson 213c, Duke University*
*Tel: 919-491-3677 <919-491-3677>*
*Email: ***@duke.edu <***@duke.edu>*
Stefan Kristiansson
2015-01-20 05:10:56 UTC
Permalink
On Tue, Jan 20, 2015 at 3:23 AM, Ziqiang Patrick Huang <
Post by Ziqiang Patrick Huang
Stefan,
Thanks for your reply, I did use the headers from upstream from
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Ok, good, but something must have went wrong when you installed them then.
If you look at the place where it failed, __NR_fstat should not be defined
for us.


I solved this problem by commenting some commands out in uclibc makefile.
Post by Ziqiang Patrick Huang
Right now I'm stuck at the below error
This is caused by the same problem.
Post by Ziqiang Patrick Huang
libc/sysdeps/linux/common/posix_fadvise.c:52:28: error: conflicting types
for 'posix_fadvise64'
strong_alias(posix_fadvise,posix_fadvise64)
^
./include/libc-symbols.h:190:26: note: in definition of macro
'_strong_alias'
extern __typeof (name) aliasname __attribute__ ((alias (#name)));
^
libc/sysdeps/linux/common/posix_fadvise.c:52:1: note: in expansion of
macro 'strong_alias'
strong_alias(posix_fadvise,posix_fadvise64)
^
./include/fcntl.h:214:12: note: previous declaration of 'posix_fadvise64'
was here
extern int posix_fadvise64 (int __fd, __off64_t __offset, __off64_t __len,
^
make: *** [libc/sysdeps/linux/common/posix_fadvise.os] Error 1
2015-01-19 17:39 GMT-05:00 Stefan Kristiansson <
On Mon, Jan 19, 2015 at 7:29 PM, Ziqiang Patrick Huang <
Post by Stefan Kristiansson
Post by Ziqiang Patrick Huang
Hi I'm trying to build uClibc toolchain by following the instructions on
http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Linux_.28uClibc.29_toolchain_.28or1k-linux-uclibc.29
When building uClibc-or1k, I got stuck at the error\
libc/sysdeps/linux/common/fstat.c:48:21: error: storage size of 'kbuf'
isn't known
struct kernel_stat kbuf;
Anyone had the same problem before ?
I bet you are using the wrong kernel headers, the instructions says to
use the headers from upstream, did you do that?
--
*Ziqiang Huang*
*Electrical and Computer Engineering*
*Hudson 213c, Duke University*
*Tel: 919-491-3677 <919-491-3677>*
Ziqiang Patrick Huang
2015-01-20 14:59:55 UTC
Permalink
Stefan,

I'm not sure where went wrong, I just tried again, start from beginning,
following the exact instruction from the website, still ends up in the same
place.

Here is the libc/sysdeps/linux/common/posix_fadvise.c where it failed,

#ifdef __NR_arm_fadvise64_64
/* We handle the 64bit alignment issue which is why the arm guys renamed
their


* syscall in the first place. So rename it back.



*/
# define __NR_fadvise64_64 __NR_arm_fadvise64_64
#endif

#if defined(__NR_fadvise64) || defined(__NR_fadvise64_64)
# include <fcntl.h>
# include <endian.h>
# include <bits/wordsize.h>

# ifdef __NR_fadvise64_64
int posix_fadvise64(int fd, off64_t offset, off64_t len, int advice);
# endif

int posix_fadvise(int fd, off_t offset, off_t len, int advice)
{
# ifdef __NR_fadvise64_64
return posix_fadvise64(fd, offset, len, advice);
# else
int ret;
INTERNAL_SYSCALL_DECL(err);
# if __WORDSIZE == 64
ret = INTERNAL_SYSCALL(fadvise64, err, 4, fd, offset, len, advice);
# else
# if defined(__UCLIBC_SYSCALL_ALIGN_64BIT__)
ret = INTERNAL_SYSCALL(fadvise64, err, 6, fd, /*unused*/0,
# else
ret = INTERNAL_SYSCALL(fadvise64, err, 5, fd,
# endif
OFF_HI_LO (offset), len, advice);
# endif
if (INTERNAL_SYSCALL_ERROR_P (ret, err))
return INTERNAL_SYSCALL_ERRNO (ret, err);
return 0;
# endif
}
# if defined __UCLIBC_HAS_LFS__ && (!defined __NR_fadvise64_64 ||
__WORDSIZE == 64)
strong_alias(posix_fadvise,posix_fadvise64)
# endif
#endif




2015-01-20 0:10 GMT-05:00 Stefan Kristiansson <
Post by Stefan Kristiansson
On Tue, Jan 20, 2015 at 3:23 AM, Ziqiang Patrick Huang <
Post by Ziqiang Patrick Huang
Stefan,
Thanks for your reply, I did use the headers from upstream from
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Ok, good, but something must have went wrong when you installed them then.
If you look at the place where it failed, __NR_fstat should not be defined
for us.
I solved this problem by commenting some commands out in uclibc makefile.
Post by Ziqiang Patrick Huang
Right now I'm stuck at the below error
This is caused by the same problem.
Post by Ziqiang Patrick Huang
libc/sysdeps/linux/common/posix_fadvise.c:52:28: error: conflicting types
for 'posix_fadvise64'
strong_alias(posix_fadvise,posix_fadvise64)
^
./include/libc-symbols.h:190:26: note: in definition of macro
'_strong_alias'
extern __typeof (name) aliasname __attribute__ ((alias (#name)));
^
libc/sysdeps/linux/common/posix_fadvise.c:52:1: note: in expansion of
macro 'strong_alias'
strong_alias(posix_fadvise,posix_fadvise64)
^
./include/fcntl.h:214:12: note: previous declaration of 'posix_fadvise64'
was here
extern int posix_fadvise64 (int __fd, __off64_t __offset, __off64_t __len,
^
make: *** [libc/sysdeps/linux/common/posix_fadvise.os] Error 1
2015-01-19 17:39 GMT-05:00 Stefan Kristiansson <
On Mon, Jan 19, 2015 at 7:29 PM, Ziqiang Patrick Huang <
Post by Stefan Kristiansson
Post by Ziqiang Patrick Huang
Hi I'm trying to build uClibc toolchain by following the instructions on
http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Linux_.28uClibc.29_toolchain_.28or1k-linux-uclibc.29
When building uClibc-or1k, I got stuck at the error\
libc/sysdeps/linux/common/fstat.c:48:21: error: storage size of 'kbuf'
isn't known
struct kernel_stat kbuf;
Anyone had the same problem before ?
I bet you are using the wrong kernel headers, the instructions says to
use the headers from upstream, did you do that?
--
*Ziqiang Huang*
*Electrical and Computer Engineering*
*Hudson 213c, Duke University*
*Tel: 919-491-3677 <919-491-3677>*
--
*Ziqiang Huang*
*Electrical and Computer Engineering*
*Hudson 213c, Duke University*
*Tel: 919-491-3677*
*Email: ***@duke.edu <***@duke.edu>*
Stefan Kristiansson
2015-01-20 15:42:20 UTC
Permalink
On Tue, Jan 20, 2015 at 4:59 PM, Ziqiang Patrick Huang <
Post by Ziqiang Patrick Huang
Stefan,
I'm not sure where went wrong, I just tried again, start from beginning,
following the exact instruction from the website, still ends up in the same
place.
Here is the libc/sysdeps/linux/common/posix_fadvise.c where it failed,
#ifdef __NR_arm_fadvise64_64
/* We handle the 64bit alignment issue which is why the arm guys renamed
their
* syscall in the first place. So rename it back.
*/
# define __NR_fadvise64_64 __NR_arm_fadvise64_64
#endif
#if defined(__NR_fadvise64) || defined(__NR_fadvise64_64)
# include <fcntl.h>
# include <endian.h>
# include <bits/wordsize.h>
# ifdef __NR_fadvise64_64
int posix_fadvise64(int fd, off64_t offset, off64_t len, int advice);
# endif
int posix_fadvise(int fd, off_t offset, off_t len, int advice)
{
# ifdef __NR_fadvise64_64
return posix_fadvise64(fd, offset, len, advice);
# else
int ret;
INTERNAL_SYSCALL_DECL(err);
# if __WORDSIZE == 64
ret = INTERNAL_SYSCALL(fadvise64, err, 4, fd, offset, len, advice);
# else
# if defined(__UCLIBC_SYSCALL_ALIGN_64BIT__)
ret = INTERNAL_SYSCALL(fadvise64, err, 6, fd, /*unused*/0,
# else
ret = INTERNAL_SYSCALL(fadvise64, err, 5, fd,
# endif
OFF_HI_LO (offset), len, advice);
# endif
if (INTERNAL_SYSCALL_ERROR_P (ret, err))
return INTERNAL_SYSCALL_ERRNO (ret, err);
return 0;
# endif
}
# if defined __UCLIBC_HAS_LFS__ && (!defined __NR_fadvise64_64 ||
__WORDSIZE == 64)
strong_alias(posix_fadvise,posix_fadvise64)
# endif
#endif
I don't know where it goes wrong for you, but you definitely end up with
the wrong kernel headers.
The code path with the 'strong_alias(posix_fadvise,posix_fadvise64)'
shouldn't be reached with the upstrean openrisc ones,
since we do define __NR_fadvise64_64 (and __WORDSIZE should not be 64).

Some sanity checks, you are installing the headers with:
ARCH=openrisc make INSTALL_HDR_PATH=${SYSROOT}/usr headers_install
right?
And you do have $SYSROOT set to something?

After you've made sure of that, try doing a 'make distclean' and then try
to build again.

Stefan
Ziqiang Patrick Huang
2015-01-20 18:07:21 UTC
Permalink
Stefan,

I did installed with ARCH=openrisc make INSTALL_HDR_PATH=${SYSROOT}/usr
headers_install
and have $SYSROOT set to /opt/or1k-toolchain/or1k-linux-uclibc/sys-root as
suggested by the instruction.
And I did installed the headers from git://
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

I double checked everything again, and rebuild after make distclean, sill
getting the same error. Is it possible that the upstream linux version is
not compatible with the upstream uclibc version ? Or is there anything else
I can check to know if I did anything wrong ?

Thanks
Patrick


2015-01-20 10:42 GMT-05:00 Stefan Kristiansson <
Post by Stefan Kristiansson
On Tue, Jan 20, 2015 at 4:59 PM, Ziqiang Patrick Huang <
Post by Ziqiang Patrick Huang
Stefan,
I'm not sure where went wrong, I just tried again, start from beginning,
following the exact instruction from the website, still ends up in the same
place.
Here is the libc/sysdeps/linux/common/posix_fadvise.c where it failed,
#ifdef __NR_arm_fadvise64_64
/* We handle the 64bit alignment issue which is why the arm guys renamed
their
* syscall in the first place. So rename it back.
*/
# define __NR_fadvise64_64 __NR_arm_fadvise64_64
#endif
#if defined(__NR_fadvise64) || defined(__NR_fadvise64_64)
# include <fcntl.h>
# include <endian.h>
# include <bits/wordsize.h>
# ifdef __NR_fadvise64_64
int posix_fadvise64(int fd, off64_t offset, off64_t len, int advice);
# endif
int posix_fadvise(int fd, off_t offset, off_t len, int advice)
{
# ifdef __NR_fadvise64_64
return posix_fadvise64(fd, offset, len, advice);
# else
int ret;
INTERNAL_SYSCALL_DECL(err);
# if __WORDSIZE == 64
ret = INTERNAL_SYSCALL(fadvise64, err, 4, fd, offset, len, advice);
# else
# if defined(__UCLIBC_SYSCALL_ALIGN_64BIT__)
ret = INTERNAL_SYSCALL(fadvise64, err, 6, fd, /*unused*/0,
# else
ret = INTERNAL_SYSCALL(fadvise64, err, 5, fd,
# endif
OFF_HI_LO (offset), len, advice);
# endif
if (INTERNAL_SYSCALL_ERROR_P (ret, err))
return INTERNAL_SYSCALL_ERRNO (ret, err);
return 0;
# endif
}
# if defined __UCLIBC_HAS_LFS__ && (!defined __NR_fadvise64_64 ||
__WORDSIZE == 64)
strong_alias(posix_fadvise,posix_fadvise64)
# endif
#endif
I don't know where it goes wrong for you, but you definitely end up with
the wrong kernel headers.
The code path with the 'strong_alias(posix_fadvise,posix_fadvise64)'
shouldn't be reached with the upstrean openrisc ones,
since we do define __NR_fadvise64_64 (and __WORDSIZE should not be 64).
ARCH=openrisc make INSTALL_HDR_PATH=${SYSROOT}/usr headers_install
right?
And you do have $SYSROOT set to something?
After you've made sure of that, try doing a 'make distclean' and then try
to build again.
Stefan
--
*Ziqiang Huang*
*Electrical and Computer Engineering*
*Hudson 213c, Duke University*
*Tel: 919-491-3677*
*Email: ***@duke.edu <***@duke.edu>*
BAndViG
2015-01-20 19:01:31 UTC
Permalink
Some time ago I build the uClibc-or1k tool chain. I checked my notes and I’ve found the following differences with official guide from OpenCores:

1) Just after cloning linux kernel it is useful to replace any obsolete occurrences of or32 by or1k:
$ cd linux
$ find ./ -type f -name '*' -print | xargs sed -i 's/or32/or1k/'

2) Just after cloning uClibc-or1k check simlink “Config” in the root folder of uClibc-or1k. Git often replaces simlinks by text files (the file contains link point). Perhaps you have to restore the simlink by hand in your working copy.
Alternatively. I’ve attached my configuration file for uClibc-or1k. You can try to copy the file into root folder of uClibc-or1k, rename it to “.config” and run make. The configuration was successfully for me.

PS. Patrick, did you receive my e-mal with Whetstone port I sent you on 16 January?


From: Ziqiang Patrick Huang
Sent: Tuesday, January 20, 2015 9:07 PM
To: Stefan Kristiansson
Cc: openrisc ; ***@lists.opencores.org
Subject: Re: [OpenRISC] Building uClibc-or1k failed: storage size unknown

Stefan,

I did installed with ARCH=openrisc make INSTALL_HDR_PATH=${SYSROOT}/usr headers_install
and have $SYSROOT set to /opt/or1k-toolchain/or1k-linux-uclibc/sys-root as suggested by the instruction.
And I did installed the headers from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git


I double checked everything again, and rebuild after make distclean, sill getting the same error. Is it possible that the upstream linux version is not compatible with the upstream uclibc version ? Or is there anything else I can check to know if I did anything wrong ?


Thanks
Patrick


2015-01-20 10:42 GMT-05:00 Stefan Kristiansson <***@saunalahti.fi>:

On Tue, Jan 20, 2015 at 4:59 PM, Ziqiang Patrick Huang <***@gmail.com> wrote:

Stefan,

I'm not sure where went wrong, I just tried again, start from beginning, following the exact instruction from the website, still ends up in the same place.

Here is the libc/sysdeps/linux/common/posix_fadvise.c where it failed,

#ifdef __NR_arm_fadvise64_64
/* We handle the 64bit alignment issue which is why the arm guys renamed their
* syscall in the first place. So rename it back.
*/
# define __NR_fadvise64_64 __NR_arm_fadvise64_64
#endif

#if defined(__NR_fadvise64) || defined(__NR_fadvise64_64)
# include <fcntl.h>
# include <endian.h>
# include <bits/wordsize.h>

# ifdef __NR_fadvise64_64
int posix_fadvise64(int fd, off64_t offset, off64_t len, int advice);
# endif

int posix_fadvise(int fd, off_t offset, off_t len, int advice)
{
# ifdef __NR_fadvise64_64
return posix_fadvise64(fd, offset, len, advice);
# else
int ret;
INTERNAL_SYSCALL_DECL(err);
# if __WORDSIZE == 64
ret = INTERNAL_SYSCALL(fadvise64, err, 4, fd, offset, len, advice);
# else
# if defined(__UCLIBC_SYSCALL_ALIGN_64BIT__)
ret = INTERNAL_SYSCALL(fadvise64, err, 6, fd, /*unused*/0,
# else
ret = INTERNAL_SYSCALL(fadvise64, err, 5, fd,
# endif
OFF_HI_LO (offset), len, advice);
# endif
if (INTERNAL_SYSCALL_ERROR_P (ret, err))
return INTERNAL_SYSCALL_ERRNO (ret, err);
return 0;
# endif
}
# if defined __UCLIBC_HAS_LFS__ && (!defined __NR_fadvise64_64 || __WORDSIZE == 64)
strong_alias(posix_fadvise,posix_fadvise64)
# endif
#endif



I don't know where it goes wrong for you, but you definitely end up with the wrong kernel headers.
The code path with the 'strong_alias(posix_fadvise,posix_fadvise64)' shouldn't be reached with the upstrean openrisc ones,
since we do define __NR_fadvise64_64 (and __WORDSIZE should not be 64).

Some sanity checks, you are installing the headers with:
ARCH=openrisc make INSTALL_HDR_PATH=${SYSROOT}/usr headers_install

right?
And you do have $SYSROOT set to something?

After you've made sure of that, try doing a 'make distclean' and then try to build again.

Stefan
--
Ziqiang Huang
Electrical and Computer Engineering
Hudson 213c, Duke University
Tel: 919-491-3677
Email: ***@duke.edu


--------------------------------------------------------------------------------
Ziqiang Patrick Huang
2015-01-20 19:58:43 UTC
Permalink
Hi Andrey

Thanks for your reply ! I tried what you mentioned, also your config file,
still does not work for me. Can I ask when were you able to build
uclib-or1k ? Did you follow the instructions here
http://opencores.org/or1k/OpenRISC_GNU_tool_chain ?
I noticed your first note is under "Hints when cross compiling with the
or1k-linux-uclibc toolchain" on the above link, however it does not mention
where to run that command.

Also I'm not sure about the following command mentioned there:

"Building with the following commands will work in a number of situations"

./configure --host=or1k-linux-uclibc
--prefix=/opt/or1k-toolchain/or1k-linux-uclibc/sys-root/usr

Since there is no configure under uclibc-or1k directory ...

I do receive your email about whetstone, thanks ! But I haven't had a
chance to look at it, since I was trying to get the toolchain ready so I
can run programs in linux from or1ksim.

Thanks again for your help.
Patrick
Post by BAndViG
Some time ago I build the uClibc-or1k tool chain. I checked my notes
1) Just after cloning linux kernel it is useful to replace any obsolete
$ cd linux
$ find ./ -type f -name '*' -print | xargs sed -i 's/or32/or1k/'
2) Just after cloning uClibc-or1k check simlink “Config” in the root
folder of uClibc-or1k. Git often replaces simlinks by text files (the file
contains link point). Perhaps you have to restore the simlink by hand in
your working copy.
Alternatively. I’ve attached my configuration file for uClibc-or1k. You
can try to copy the file into root folder of uClibc-or1k, rename it to
“.config” and run make. The configuration was successfully for me.
PS. Patrick, did you receive my e-mal with Whetstone port I sent you on 16 January?
*Sent:* Tuesday, January 20, 2015 9:07 PM
*Subject:* Re: [OpenRISC] Building uClibc-or1k failed: storage size
unknown
Stefan,
I did installed with ARCH=openrisc make INSTALL_HDR_PATH=${SYSROOT}/usr headers_install
and have $SYSROOT set to /opt/or1k-toolchain/or1k-linux-uclibc/sys-root as
suggested by the instruction.
And I did installed the headers from git://
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
I double checked everything again, and rebuild after make distclean, sill
getting the same error. Is it possible that the upstream linux version is
not compatible with the upstream uclibc version ? Or is there anything else
I can check to know if I did anything wrong ?
Thanks
Patrick
2015-01-20 10:42 GMT-05:00 Stefan Kristiansson <
Post by Stefan Kristiansson
On Tue, Jan 20, 2015 at 4:59 PM, Ziqiang Patrick Huang <
Post by Ziqiang Patrick Huang
Stefan,
I'm not sure where went wrong, I just tried again, start from beginning,
following the exact instruction from the website, still ends up in the same
place.
Here is the libc/sysdeps/linux/common/posix_fadvise.c where it failed,
#ifdef __NR_arm_fadvise64_64
/* We handle the 64bit alignment issue which is why the arm guys renamed their
* syscall in the first place. So rename it
back.
*/
# define __NR_fadvise64_64 __NR_arm_fadvise64_64
#endif
#if defined(__NR_fadvise64) || defined(__NR_fadvise64_64)
# include <fcntl.h>
# include <endian.h>
# include <bits/wordsize.h>
# ifdef __NR_fadvise64_64
int posix_fadvise64(int fd, off64_t offset, off64_t len, int advice);
# endif
int posix_fadvise(int fd, off_t offset, off_t len, int advice)
{
# ifdef __NR_fadvise64_64
return posix_fadvise64(fd, offset, len, advice);
# else
int ret;
INTERNAL_SYSCALL_DECL(err);
# if __WORDSIZE == 64
ret = INTERNAL_SYSCALL(fadvise64, err, 4, fd, offset, len, advice);
# else
# if defined(__UCLIBC_SYSCALL_ALIGN_64BIT__)
ret = INTERNAL_SYSCALL(fadvise64, err, 6, fd, /*unused*/0,
# else
ret = INTERNAL_SYSCALL(fadvise64, err, 5, fd,
# endif
OFF_HI_LO (offset), len, advice);
# endif
if (INTERNAL_SYSCALL_ERROR_P (ret, err))
return INTERNAL_SYSCALL_ERRNO (ret, err);
return 0;
# endif
}
# if defined __UCLIBC_HAS_LFS__ && (!defined __NR_fadvise64_64 || __WORDSIZE == 64)
strong_alias(posix_fadvise,posix_fadvise64)
# endif
#endif
I don't know where it goes wrong for you, but you definitely end up with
the wrong kernel headers.
The code path with the 'strong_alias(posix_fadvise,posix_fadvise64)'
shouldn't be reached with the upstrean openrisc ones,
since we do define __NR_fadvise64_64 (and __WORDSIZE should not be 64).
ARCH=openrisc make INSTALL_HDR_PATH=${SYSROOT}/usr headers_install
right?
And you do have $SYSROOT set to something?
After you've made sure of that, try doing a 'make distclean' and then try to build again.
Stefan
--
*Ziqiang Huang*
*Electrical and Computer Engineering*
*Hudson 213c, Duke University*
*Tel: 919-491-3677 <919-491-3677>*
------------------------------
_______________________________________________
OpenRISC mailing list
http://lists.openrisc.net/listinfo/openrisc
--
*Ziqiang Huang*
*Electrical and Computer Engineering*
*Hudson 213c, Duke University*
*Tel: 919-491-3677*
*Email: ***@duke.edu <***@duke.edu>*
Olof Kindgren
2015-01-20 20:42:28 UTC
Permalink
Hi Patrick,

I don't have any ideas for how to solve your problems with uClibc, but
if you just want a toolchain to compile Linux programs you could
perhaps try the one based on musl instead. I believe that one has been
used a lot more recently, so it might work better. There are some
instructions for how to build the musl toolchain here
http://www.openwall.com/lists/musl/2014/07/19/5 Not sure however if
this is the preferred way to do it. Stefan would know more about that

//Olof

On Tue, Jan 20, 2015 at 8:58 PM, Ziqiang Patrick Huang
Post by Ziqiang Patrick Huang
Hi Andrey
Thanks for your reply ! I tried what you mentioned, also your config file,
still does not work for me. Can I ask when were you able to build uclib-or1k
? Did you follow the instructions here
http://opencores.org/or1k/OpenRISC_GNU_tool_chain ?
I noticed your first note is under "Hints when cross compiling with the
or1k-linux-uclibc toolchain" on the above link, however it does not mention
where to run that command.
"Building with the following commands will work in a number of situations"
./configure --host=or1k-linux-uclibc
--prefix=/opt/or1k-toolchain/or1k-linux-uclibc/sys-root/usr
Since there is no configure under uclibc-or1k directory ...
I do receive your email about whetstone, thanks ! But I haven't had a chance
to look at it, since I was trying to get the toolchain ready so I can run
programs in linux from or1ksim.
Thanks again for your help.
Patrick
Post by BAndViG
Some time ago I build the uClibc-or1k tool chain. I checked my notes and
1) Just after cloning linux kernel it is useful to replace any obsolete
$ cd linux
$ find ./ -type f -name '*' -print | xargs sed -i 's/or32/or1k/'
2) Just after cloning uClibc-or1k check simlink “Config” in the root
folder of uClibc-or1k. Git often replaces simlinks by text files (the file
contains link point). Perhaps you have to restore the simlink by hand in
your working copy.
Alternatively. I’ve attached my configuration file for uClibc-or1k. You
can try to copy the file into root folder of uClibc-or1k, rename it to
“.config” and run make. The configuration was successfully for me.
PS. Patrick, did you receive my e-mal with Whetstone port I sent you on 16 January?
From: Ziqiang Patrick Huang
Sent: Tuesday, January 20, 2015 9:07 PM
To: Stefan Kristiansson
Subject: Re: [OpenRISC] Building uClibc-or1k failed: storage size unknown
Stefan,
I did installed with ARCH=openrisc make INSTALL_HDR_PATH=${SYSROOT}/usr headers_install
and have $SYSROOT set to /opt/or1k-toolchain/or1k-linux-uclibc/sys-root as
suggested by the instruction.
And I did installed the headers from
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
I double checked everything again, and rebuild after make distclean, sill
getting the same error. Is it possible that the upstream linux version is
not compatible with the upstream uclibc version ? Or is there anything else
I can check to know if I did anything wrong ?
Thanks
Patrick
2015-01-20 10:42 GMT-05:00 Stefan Kristiansson
Post by Stefan Kristiansson
On Tue, Jan 20, 2015 at 4:59 PM, Ziqiang Patrick Huang
Post by Ziqiang Patrick Huang
Stefan,
I'm not sure where went wrong, I just tried again, start from beginning,
following the exact instruction from the website, still ends up in the same
place.
Here is the libc/sysdeps/linux/common/posix_fadvise.c where it failed,
#ifdef __NR_arm_fadvise64_64
/* We handle the 64bit alignment issue which is why the arm guys renamed their
* syscall in the first place. So rename it back.
*/
# define __NR_fadvise64_64 __NR_arm_fadvise64_64
#endif
#if defined(__NR_fadvise64) || defined(__NR_fadvise64_64)
# include <fcntl.h>
# include <endian.h>
# include <bits/wordsize.h>
# ifdef __NR_fadvise64_64
int posix_fadvise64(int fd, off64_t offset, off64_t len, int advice);
# endif
int posix_fadvise(int fd, off_t offset, off_t len, int advice)
{
# ifdef __NR_fadvise64_64
return posix_fadvise64(fd, offset, len, advice);
# else
int ret;
INTERNAL_SYSCALL_DECL(err);
# if __WORDSIZE == 64
ret = INTERNAL_SYSCALL(fadvise64, err, 4, fd, offset, len, advice);
# else
# if defined(__UCLIBC_SYSCALL_ALIGN_64BIT__)
ret = INTERNAL_SYSCALL(fadvise64, err, 6, fd, /*unused*/0,
# else
ret = INTERNAL_SYSCALL(fadvise64, err, 5, fd,
# endif
OFF_HI_LO (offset), len, advice);
# endif
if (INTERNAL_SYSCALL_ERROR_P (ret, err))
return INTERNAL_SYSCALL_ERRNO (ret, err);
return 0;
# endif
}
# if defined __UCLIBC_HAS_LFS__ && (!defined __NR_fadvise64_64 || __WORDSIZE == 64)
strong_alias(posix_fadvise,posix_fadvise64)
# endif
#endif
I don't know where it goes wrong for you, but you definitely end up with
the wrong kernel headers.
The code path with the 'strong_alias(posix_fadvise,posix_fadvise64)'
shouldn't be reached with the upstrean openrisc ones,
since we do define __NR_fadvise64_64 (and __WORDSIZE should not be 64).
ARCH=openrisc make INSTALL_HDR_PATH=${SYSROOT}/usr headers_install
right?
And you do have $SYSROOT set to something?
After you've made sure of that, try doing a 'make distclean' and then try
to build again.
Stefan
--
Ziqiang Huang
Electrical and Computer Engineering
Hudson 213c, Duke University
Tel: 919-491-3677
________________________________
_______________________________________________
OpenRISC mailing list
http://lists.openrisc.net/listinfo/openrisc
--
Ziqiang Huang
Electrical and Computer Engineering
Hudson 213c, Duke University
Tel: 919-491-3677
_______________________________________________
OpenRISC mailing list
http://lists.openrisc.net/listinfo/openrisc
Ziqiang Patrick Huang
2015-01-21 05:53:10 UTC
Permalink
Hi Olof,

Thanks so much for your suggestion ! I followed the instructions you
poitnted to me and were able to build musl toolchain and also boot linux in
or1ksim. I noticed there were 2 versions of gccs: or1k-linux-musl-gcc &
or1k-musl-linux-gcc. I'm not sure which one is for compiling linux
application, so I tried using both of them to compile a simple hello c
program and put them under initramfs. However when I tried to run them
inside the booted linux, neither were able to run. I assume I can just do
./hello But got "bin/sh: ./hello: not found".

Patrick
Post by Olof Kindgren
Hi Patrick,
I don't have any ideas for how to solve your problems with uClibc, but
if you just want a toolchain to compile Linux programs you could
perhaps try the one based on musl instead. I believe that one has been
used a lot more recently, so it might work better. There are some
instructions for how to build the musl toolchain here
http://www.openwall.com/lists/musl/2014/07/19/5 Not sure however if
this is the preferred way to do it. Stefan would know more about that
//Olof
On Tue, Jan 20, 2015 at 8:58 PM, Ziqiang Patrick Huang
Post by Ziqiang Patrick Huang
Hi Andrey
Thanks for your reply ! I tried what you mentioned, also your config
file,
Post by Ziqiang Patrick Huang
still does not work for me. Can I ask when were you able to build
uclib-or1k
Post by Ziqiang Patrick Huang
? Did you follow the instructions here
http://opencores.org/or1k/OpenRISC_GNU_tool_chain ?
I noticed your first note is under "Hints when cross compiling with the
or1k-linux-uclibc toolchain" on the above link, however it does not
mention
Post by Ziqiang Patrick Huang
where to run that command.
"Building with the following commands will work in a number of
situations"
Post by Ziqiang Patrick Huang
./configure --host=or1k-linux-uclibc
--prefix=/opt/or1k-toolchain/or1k-linux-uclibc/sys-root/usr
Since there is no configure under uclibc-or1k directory ...
I do receive your email about whetstone, thanks ! But I haven't had a
chance
Post by Ziqiang Patrick Huang
to look at it, since I was trying to get the toolchain ready so I can run
programs in linux from or1ksim.
Thanks again for your help.
Patrick
Post by BAndViG
Some time ago I build the uClibc-or1k tool chain. I checked my notes
and
Post by Ziqiang Patrick Huang
Post by BAndViG
1) Just after cloning linux kernel it is useful to replace any obsolete
$ cd linux
$ find ./ -type f -name '*' -print | xargs sed -i 's/or32/or1k/'
2) Just after cloning uClibc-or1k check simlink “Config” in the root
folder of uClibc-or1k. Git often replaces simlinks by text files (the
file
Post by Ziqiang Patrick Huang
Post by BAndViG
contains link point). Perhaps you have to restore the simlink by hand in
your working copy.
Alternatively. I’ve attached my configuration file for uClibc-or1k. You
can try to copy the file into root folder of uClibc-or1k, rename it to
“.config” and run make. The configuration was successfully for me.
PS. Patrick, did you receive my e-mal with Whetstone port I sent you on
16
Post by Ziqiang Patrick Huang
Post by BAndViG
January?
From: Ziqiang Patrick Huang
Sent: Tuesday, January 20, 2015 9:07 PM
To: Stefan Kristiansson
Subject: Re: [OpenRISC] Building uClibc-or1k failed: storage size
unknown
Post by Ziqiang Patrick Huang
Post by BAndViG
Stefan,
I did installed with ARCH=openrisc make INSTALL_HDR_PATH=${SYSROOT}/usr
headers_install
and have $SYSROOT set to /opt/or1k-toolchain/or1k-linux-uclibc/sys-root
as
Post by Ziqiang Patrick Huang
Post by BAndViG
suggested by the instruction.
And I did installed the headers from
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
I double checked everything again, and rebuild after make distclean,
sill
Post by Ziqiang Patrick Huang
Post by BAndViG
getting the same error. Is it possible that the upstream linux version
is
Post by Ziqiang Patrick Huang
Post by BAndViG
not compatible with the upstream uclibc version ? Or is there anything
else
Post by Ziqiang Patrick Huang
Post by BAndViG
I can check to know if I did anything wrong ?
Thanks
Patrick
2015-01-20 10:42 GMT-05:00 Stefan Kristiansson
Post by Stefan Kristiansson
On Tue, Jan 20, 2015 at 4:59 PM, Ziqiang Patrick Huang
Post by Ziqiang Patrick Huang
Stefan,
I'm not sure where went wrong, I just tried again, start from
beginning,
Post by Ziqiang Patrick Huang
Post by BAndViG
Post by Stefan Kristiansson
Post by Ziqiang Patrick Huang
following the exact instruction from the website, still ends up in
the same
Post by Ziqiang Patrick Huang
Post by BAndViG
Post by Stefan Kristiansson
Post by Ziqiang Patrick Huang
place.
Here is the libc/sysdeps/linux/common/posix_fadvise.c where it
failed,
Post by Ziqiang Patrick Huang
Post by BAndViG
Post by Stefan Kristiansson
Post by Ziqiang Patrick Huang
#ifdef __NR_arm_fadvise64_64
/* We handle the 64bit alignment issue which is why the arm guys
renamed
Post by Ziqiang Patrick Huang
Post by BAndViG
Post by Stefan Kristiansson
Post by Ziqiang Patrick Huang
their
* syscall in the first place. So rename it back.
*/
# define __NR_fadvise64_64 __NR_arm_fadvise64_64
#endif
#if defined(__NR_fadvise64) || defined(__NR_fadvise64_64)
# include <fcntl.h>
# include <endian.h>
# include <bits/wordsize.h>
# ifdef __NR_fadvise64_64
int posix_fadvise64(int fd, off64_t offset, off64_t len, int advice);
# endif
int posix_fadvise(int fd, off_t offset, off_t len, int advice)
{
# ifdef __NR_fadvise64_64
return posix_fadvise64(fd, offset, len, advice);
# else
int ret;
INTERNAL_SYSCALL_DECL(err);
# if __WORDSIZE == 64
ret = INTERNAL_SYSCALL(fadvise64, err, 4, fd, offset, len, advice);
# else
# if defined(__UCLIBC_SYSCALL_ALIGN_64BIT__)
ret = INTERNAL_SYSCALL(fadvise64, err, 6, fd, /*unused*/0,
# else
ret = INTERNAL_SYSCALL(fadvise64, err, 5, fd,
# endif
OFF_HI_LO (offset), len, advice);
# endif
if (INTERNAL_SYSCALL_ERROR_P (ret, err))
return INTERNAL_SYSCALL_ERRNO (ret, err);
return 0;
# endif
}
# if defined __UCLIBC_HAS_LFS__ && (!defined __NR_fadvise64_64 ||
__WORDSIZE == 64)
strong_alias(posix_fadvise,posix_fadvise64)
# endif
#endif
I don't know where it goes wrong for you, but you definitely end up
with
Post by Ziqiang Patrick Huang
Post by BAndViG
Post by Stefan Kristiansson
the wrong kernel headers.
The code path with the 'strong_alias(posix_fadvise,posix_fadvise64)'
shouldn't be reached with the upstrean openrisc ones,
since we do define __NR_fadvise64_64 (and __WORDSIZE should not be 64).
ARCH=openrisc make INSTALL_HDR_PATH=${SYSROOT}/usr headers_install
right?
And you do have $SYSROOT set to something?
After you've made sure of that, try doing a 'make distclean' and then
try
Post by Ziqiang Patrick Huang
Post by BAndViG
Post by Stefan Kristiansson
to build again.
Stefan
--
Ziqiang Huang
Electrical and Computer Engineering
Hudson 213c, Duke University
Tel: 919-491-3677
________________________________
_______________________________________________
OpenRISC mailing list
http://lists.openrisc.net/listinfo/openrisc
--
Ziqiang Huang
Electrical and Computer Engineering
Hudson 213c, Duke University
Tel: 919-491-3677
_______________________________________________
OpenRISC mailing list
http://lists.openrisc.net/listinfo/openrisc
--
*Ziqiang Huang*
*Electrical and Computer Engineering*
*Hudson 213c, Duke University*
*Tel: 919-491-3677*
*Email: ***@duke.edu <***@duke.edu>*
Stefan Kristiansson
2015-01-21 06:09:59 UTC
Permalink
On Wed, Jan 21, 2015 at 7:53 AM, Ziqiang Patrick Huang <
Post by Ziqiang Patrick Huang
Hi Olof,
Thanks so much for your suggestion ! I followed the instructions you
poitnted to me and were able to build musl toolchain and also boot linux in
or1ksim. I noticed there were 2 versions of gccs: or1k-linux-musl-gcc &
or1k-musl-linux-gcc. I'm not sure which one is for compiling linux
application, so I tried using both of them to compile a simple hello c
program and put them under initramfs. However when I tried to run them
inside the booted linux, neither were able to run. I assume I can just do
./hello But got "bin/sh: ./hello: not found".
You will need to copy the dynamic libraries from musl into your initramfs
(at the very minimum, you'll at least need libc.so).
Regarding or1k-musl-linux-gcc vs or1k-linux-musl-gcc, I had never noticed
the or1k-musl-linux-gcc, but you are right, it's there.
It's however just a symlink to or1k-linux-musl-gcc.

Stefan
Ziqiang Patrick Huang
2015-01-21 15:03:30 UTC
Permalink
Hi Stefan,

I copied libc.so from musl-cross/musl-master/lib to
arch/openrisc/support/initramfs/

./hello still gives me ./hello not found, seems like it's still not
recognizing the executable file.

How should I run it ?

Patrick

2015-01-21 1:09 GMT-05:00 Stefan Kristiansson <
Post by Stefan Kristiansson
On Wed, Jan 21, 2015 at 7:53 AM, Ziqiang Patrick Huang <
Post by Ziqiang Patrick Huang
Hi Olof,
Thanks so much for your suggestion ! I followed the instructions you
poitnted to me and were able to build musl toolchain and also boot linux in
or1ksim. I noticed there were 2 versions of gccs: or1k-linux-musl-gcc &
or1k-musl-linux-gcc. I'm not sure which one is for compiling linux
application, so I tried using both of them to compile a simple hello c
program and put them under initramfs. However when I tried to run them
inside the booted linux, neither were able to run. I assume I can just do
./hello But got "bin/sh: ./hello: not found".
You will need to copy the dynamic libraries from musl into your initramfs
(at the very minimum, you'll at least need libc.so).
Regarding or1k-musl-linux-gcc vs or1k-linux-musl-gcc, I had never noticed
the or1k-musl-linux-gcc, but you are right, it's there.
It's however just a symlink to or1k-linux-musl-gcc.
Stefan
--
*Ziqiang Huang*
*Electrical and Computer Engineering*
*Hudson 213c, Duke University*
*Tel: 919-491-3677*
*Email: ***@duke.edu <***@duke.edu>*
Ziqiang Patrick Huang
2015-01-21 15:23:55 UTC
Permalink
compiling using -static solve the problem. How do I tell the executable to
pick libc.so if I want to use dynamic linking ?

2015-01-21 10:03 GMT-05:00 Ziqiang Patrick Huang <
Post by Ziqiang Patrick Huang
Hi Stefan,
I copied libc.so from musl-cross/musl-master/lib to
arch/openrisc/support/initramfs/
./hello still gives me ./hello not found, seems like it's still not
recognizing the executable file.
How should I run it ?
Patrick
2015-01-21 1:09 GMT-05:00 Stefan Kristiansson <
On Wed, Jan 21, 2015 at 7:53 AM, Ziqiang Patrick Huang <
Post by Stefan Kristiansson
Post by Ziqiang Patrick Huang
Hi Olof,
Thanks so much for your suggestion ! I followed the instructions you
poitnted to me and were able to build musl toolchain and also boot linux in
or1ksim. I noticed there were 2 versions of gccs: or1k-linux-musl-gcc &
or1k-musl-linux-gcc. I'm not sure which one is for compiling linux
application, so I tried using both of them to compile a simple hello c
program and put them under initramfs. However when I tried to run them
inside the booted linux, neither were able to run. I assume I can just do
./hello But got "bin/sh: ./hello: not found".
You will need to copy the dynamic libraries from musl into your initramfs
(at the very minimum, you'll at least need libc.so).
Regarding or1k-musl-linux-gcc vs or1k-linux-musl-gcc, I had never noticed
the or1k-musl-linux-gcc, but you are right, it's there.
It's however just a symlink to or1k-linux-musl-gcc.
Stefan
--
*Ziqiang Huang*
*Electrical and Computer Engineering*
*Hudson 213c, Duke University*
*Tel: 919-491-3677 <919-491-3677>*
--
*Ziqiang Huang*
*Electrical and Computer Engineering*
*Hudson 213c, Duke University*
*Tel: 919-491-3677*
*Email: ***@duke.edu <***@duke.edu>*
Stefan Kristiansson
2015-01-21 15:32:39 UTC
Permalink
On Wed, Jan 21, 2015 at 5:03 PM, Ziqiang Patrick Huang
Post by Ziqiang Patrick Huang
Hi Stefan,
I copied libc.so from musl-cross/musl-master/lib to arch/openrisc/support/initramfs/
./hello still gives me ./hello not found, seems like it's still not recognizing the executable file.
How should I run it ?
Sorry, I should probably have been more explicit, you should copy the
.so's into arch/openrisc/support/initramfs/lib/
And you will also need to create a symlink called ld-musl-or1k.so.1
that points to libc.so.
This is an example how the lib dir can look like:

~ # ls -al /lib/
total 3208
drwxrwxr-x 2 1000 1000 540 Jan 10 2015 .
drwxrwxrwt 15 root 0 480 Jan 2 03:50 ..
lrwxrwxrwx 1 1000 1000 7 Jan 10 2015
ld-musl-or1k.so.1 -> libc.so
-rwxr-xr-x 1 1000 1000 991 Jan 9 2015 libatomic.la
lrwxrwxrwx 1 1000 1000 18 Jan 10 2015 libatomic.so
-> libatomic.so.1.1.0
lrwxrwxrwx 1 1000 1000 18 Jan 10 2015
libatomic.so.1 -> libatomic.so.1.1.0
-rwxr-xr-x 1 1000 1000 82058 Jan 9 2015 libatomic.so.1.1.0
-rwxr-xr-x 1 1000 1000 1049654 Jan 7 2015 libc.so
lrwxrwxrwx 1 1000 1000 13 Jan 10 2015 libgcc_s.so
-> libgcc_s.so.1
-rw-r--r-- 1 1000 1000 372527 Jan 9 2015 libgcc_s.so.1
-rwxr-xr-x 1 1000 1000 968 Jan 9 2015 libgomp.la
lrwxrwxrwx 1 1000 1000 16 Jan 10 2015 libgomp.so ->
libgomp.so.1.0.0
lrwxrwxrwx 1 1000 1000 16 Jan 10 2015 libgomp.so.1
-> libgomp.so.1.0.0
-rwxr-xr-x 1 1000 1000 428186 Jan 9 2015 libgomp.so.1.0.0
-rw-r--r-- 1 1000 1000 164 Jan 9 2015 libgomp.spec
-rwxr-xr-x 1 1000 1000 961 Jan 9 2015 libssp.la
lrwxrwxrwx 1 1000 1000 15 Jan 10 2015 libssp.so ->
libssp.so.0.0.0
lrwxrwxrwx 1 1000 1000 15 Jan 10 2015 libssp.so.0
-> libssp.so.0.0.0
-rwxr-xr-x 1 1000 1000 26350 Jan 9 2015 libssp.so.0.0.0
-rwxr-xr-x 1 1000 1000 943 Jan 9 2015 libssp_nonshared.la
-rwxr-xr-x 1 1000 1000 988 Jan 9 2015 libstdc++.la
lrwxrwxrwx 1 1000 1000 19 Jan 10 2015 libstdc++.so
-> libstdc++.so.6.0.20
lrwxrwxrwx 1 1000 1000 19 Jan 10 2015
libstdc++.so.6 -> libstdc++.so.6.0.20
-rwxr-xr-x 1 1000 1000 1219766 Jan 9 2015 libstdc++.so.6.0.20
-rw-r--r-- 1 1000 1000 2352 Jan 9 2015
libstdc++.so.6.0.20-gdb.py
-rwxr-xr-x 1 1000 1000 922 Jan 9 2015 libsupc++.la
-rw-r--r-- 1 1000 1000 842 Jul 19 2014 musl-gcc.specs

Stefan
Ziqiang Patrick Huang
2015-01-21 15:45:44 UTC
Permalink
Thanks ! This helps a lot. Where can I find all these .so files, right now
I only see libc.so under /musl-cross/musl-master/lib

2015-01-21 10:32 GMT-05:00 Stefan Kristiansson <
Post by Stefan Kristiansson
On Wed, Jan 21, 2015 at 5:03 PM, Ziqiang Patrick Huang
Post by Ziqiang Patrick Huang
Hi Stefan,
I copied libc.so from musl-cross/musl-master/lib to
arch/openrisc/support/initramfs/
Post by Ziqiang Patrick Huang
./hello still gives me ./hello not found, seems like it's still not
recognizing the executable file.
Post by Ziqiang Patrick Huang
How should I run it ?
Sorry, I should probably have been more explicit, you should copy the
.so's into arch/openrisc/support/initramfs/lib/
And you will also need to create a symlink called ld-musl-or1k.so.1
that points to libc.so.
~ # ls -al /lib/
total 3208
drwxrwxr-x 2 1000 1000 540 Jan 10 2015 .
drwxrwxrwt 15 root 0 480 Jan 2 03:50 ..
lrwxrwxrwx 1 1000 1000 7 Jan 10 2015
ld-musl-or1k.so.1 -> libc.so
-rwxr-xr-x 1 1000 1000 991 Jan 9 2015 libatomic.la
lrwxrwxrwx 1 1000 1000 18 Jan 10 2015 libatomic.so
-> libatomic.so.1.1.0
lrwxrwxrwx 1 1000 1000 18 Jan 10 2015
libatomic.so.1 -> libatomic.so.1.1.0
-rwxr-xr-x 1 1000 1000 82058 Jan 9 2015 libatomic.so.1.1.0
-rwxr-xr-x 1 1000 1000 1049654 Jan 7 2015 libc.so
lrwxrwxrwx 1 1000 1000 13 Jan 10 2015 libgcc_s.so
-> libgcc_s.so.1
-rw-r--r-- 1 1000 1000 372527 Jan 9 2015 libgcc_s.so.1
-rwxr-xr-x 1 1000 1000 968 Jan 9 2015 libgomp.la
lrwxrwxrwx 1 1000 1000 16 Jan 10 2015 libgomp.so ->
libgomp.so.1.0.0
lrwxrwxrwx 1 1000 1000 16 Jan 10 2015 libgomp.so.1
-> libgomp.so.1.0.0
-rwxr-xr-x 1 1000 1000 428186 Jan 9 2015 libgomp.so.1.0.0
-rw-r--r-- 1 1000 1000 164 Jan 9 2015 libgomp.spec
-rwxr-xr-x 1 1000 1000 961 Jan 9 2015 libssp.la
lrwxrwxrwx 1 1000 1000 15 Jan 10 2015 libssp.so ->
libssp.so.0.0.0
lrwxrwxrwx 1 1000 1000 15 Jan 10 2015 libssp.so.0
-> libssp.so.0.0.0
-rwxr-xr-x 1 1000 1000 26350 Jan 9 2015 libssp.so.0.0.0
-rwxr-xr-x 1 1000 1000 943 Jan 9 2015
libssp_nonshared.la
-rwxr-xr-x 1 1000 1000 988 Jan 9 2015 libstdc++.la
lrwxrwxrwx 1 1000 1000 19 Jan 10 2015 libstdc++.so
-> libstdc++.so.6.0.20
lrwxrwxrwx 1 1000 1000 19 Jan 10 2015
libstdc++.so.6 -> libstdc++.so.6.0.20
-rwxr-xr-x 1 1000 1000 1219766 Jan 9 2015
libstdc++.so.6.0.20
-rw-r--r-- 1 1000 1000 2352 Jan 9 2015
libstdc++.so.6.0.20-gdb.py
-rwxr-xr-x 1 1000 1000 922 Jan 9 2015 libsupc++.la
-rw-r--r-- 1 1000 1000 842 Jul 19 2014 musl-gcc.specs
Stefan
--
*Ziqiang Huang*
*Electrical and Computer Engineering*
*Hudson 213c, Duke University*
*Tel: 919-491-3677*
*Email: ***@duke.edu <***@duke.edu>*
Loading...