You are not logged in.
Thanks for the fakeroot tip.
KVM is not supported by my cpu
I am trying to build packages in a cross-compilation setup atm but building natively would make me feel a lot better about it
There also seems to be some issue with make hanging and just not doing anything anymore that I think is related to pflocal. Really everything breaks Hurd in some way
btw networking works if you use -net nic,vlan=1,model=pcnet in the qemu commandline instead of using the default model for nic
Last edited by melpo (2010-03-08 21:53:35)
Offline
Well it is getting quiet here....
But anyways I now have a crosshurd script which builds working makepkg, pacman and gcc
I also managed to make all the packages required for a very minimalistic booting hurd (gnumach, hurd, glibc, coreutils, grub, bash) and nothing broke after testing them
@Allan: Does the offer for hosting crosshurd tarballs still stand, pretty please? (I srsly need to get myself some webspace )
Offline
Well it is getting quiet here....
But anyways I now have a crosshurd script which builds working makepkg, pacman and gcc
I also managed to make all the packages required for a very minimalistic booting hurd (gnumach, hurd, glibc, coreutils, grub, bash) and nothing broke after testing them
Thats fantastic! Well done
====* -- Joke
O
\|/ --- Me
/ \ Whooooosh
Offline
@Allan: Does the offer for hosting crosshurd tarballs still stand, pretty please?
Yes !! Let's fill up the repo !
It's presently kind of empty...
http://www.archhurd.org/packages.php
In a world without walls and fences, who needs windows and gates ?
Offline
I've been a bit distracted from this recently but, if someone wants SSH/Git access to the server, just ask nicely
Offline
@Allan: Does the offer for hosting crosshurd tarballs still stand, pretty please? (I srsly need to get myself some webspace )
It sure does.
Offline
melpo wrote:@Allan: Does the offer for hosting crosshurd tarballs still stand, pretty please? (I srsly need to get myself some webspace )
It sure does.
And here we go: http://allanmcrae.com/hurd/melpo/crossh … 12.tar.bz2
This looks awesome! It seems to be at the point where actual package making can start. I highly recommend adjusting PKGBUILDs to always have separate build() and install() function to limit fakeroot usage given its issues.
As an aside, I see pacman is an offender in the PATH_MAX arena... In fact, I know it is given I just submitted a patch using it. We can look at getting a propper fix in upstream pacman at a later stage. The configure.ac changes can probably go there now (I do not understand the first change at first glance).
Offline
As an aside, I see pacman is an offender in the PATH_MAX arena... In fact, I know it is given I just submitted a patch using it. We can look at getting a propper fix in upstream pacman at a later stage. The configure.ac changes can probably go there now (I do not understand the first change at first glance).
pacman is the main offender using PATH_MAX
The first patch is necessary because when testing for libfetch only -lfetch is linked which will result in an undefined references errors.
The second one to configure.ac is more fun, when cross-compiling configure will error because AC_CHECK_PROGS for git (which was always called) throws an error when cross-compiling. Now all the patch does is move the check inside the if so that it is only executed if --enable-git is actually set.
Thanks for mentioning it, I totally missed that this should go to upstream. (the first one with the linking errors too?)
Offline
Congratulations, melpo! No put the Arch Hurd website link in your sig already!
@Allan
Haven't seen you use a smiley in any of your posts until now, so this has to be something big, doesn't it
Offline
@Allan
Haven't seen you use a smiley in any of your posts until now, so this has to be something big, doesn't it
Massive!!!
Thanks for mentioning it, I totally missed that this should go to upstream. (the first one with the linking errors too?)
Yes, send both the configure.ac changes to the pacman-dev mailing list with an explanation. It seems they both are cross-compiling issues which probably have not been struck before. I can open a bug report to suggest fixing the PATH_MAX stuff (or at least do like "file" does and get a define in there as a fallback).
Offline
Offline
Oh, Melpo, with your new-found server powers, feel free to update the news. It's a bit behind
Offline
openssl is compiling, but there is no libssl.so*
Yeah I still have to fully figure out the openssl Configure script, it's a "unique". Will post as soon as I figure it out.
Oh, Melpo, with your new-found server powers, feel free to update the news. It's a bit behind
Done already . Adding packages is seriously broken btw and my php skills are too non-existant to do anything about it
Did you hide the script to update the repo db really well or is there none(how did you get your pacakge in the extra db)?
Offline
Done already . Adding packages is seriously broken btw and my php skills are too non-existant to do anything about it
Did you hide the script to update the repo db really well or is there none(how did you get your pacakge in the extra db)?
I've just uploaded the repo-add and repo-remove scripts to ~/bin, and I'll work on the PHP later.
Offline
I am trying to build openssl in hurd with makepkg but it says "cc command not found" but gcc works. Any Ideas?
EDIT:
I don't have perl.
But i need it to build openssl
EDIT2:
Giselher wrote:openssl is compiling, but there is no libssl.so*
Yeah I still have to fully figure out the openssl Configure script, it's a "unique". Will post as soon as I figure it out.
You have to change the line:
./Configure hurd-x86 --prefix= --shared
It can compile the libssl.so in the $ROOT/build but i get an install error about libcrypto.
But i have a libssl.so
Last edited by Giselher (2010-03-14 10:19:42)
Offline
> file /usr/bin/cc
/usr/bin/cc: symbolic link to `gcc'
So maybe just a symlink needed in your Hurd path. Otherwise look in configure.log for more details on the error.
Offline
> file /usr/bin/cc /usr/bin/cc: symbolic link to `gcc'
So maybe just a symlink needed in your Hurd path. Otherwise look in configure.log for more details on the error.
Thanks, it looks like it will working, but it takes so long.
EDIT:
No, I need perl for building openssl nativ.
Last edited by Giselher (2010-03-14 10:33:25)
Offline
I made 3 crosshurd scripts for gdbm db and perl and i will now test if perl works in hurd.
EDIT:
BTW: pacman needs libc.so.6. Maybe this has something to do with openssl.
Last edited by Giselher (2010-03-14 13:57:13)
Offline
Are you sure about your pacman needing libc.so.6? That seems a bit weird. Here's my pacman ldd:
I am pretty sure that perl works on hurd, compiling it will be the challenge.
There is an instruction for cross-compiling in the README if I remember correctly
(Something about running the configure script natively and copying some files to the build dir)
Please update us on this, havin perl would be great as many packages rely on it for building.
@Barrucadu: yay thanks
Offline
Are you sure about your pacman needing libc.so.6? That seems a bit weird. Here's my pacman ldd: http://img96.imageshack.us/img96/5741/s … pacman.png
I am pretty sure that perl works on hurd, compiling it will be the challenge.
There is an instruction for cross-compiling in the README if I remember correctly
(Something about running the configure script natively and copying some files to the build dir)
Please update us on this, havin perl would be great as many packages rely on it for building.@Barrucadu: yay thanks
Yupe
And i can't compile pacman again.
checking where the gettext function comes from... libc
checking for archive_read_data in -larchive... yes
checking whether to link with libfetch... yes
checking for fetchParseURL in -lfetch... no
configure: error: libfetch is needed to compile with internal download support
make: *** No rule to make target `install'. Stop.
---
The perl configure script says that gcc doesn't work, but it should work.
EDIT: gcc really doesn't work and i don't have any backup of my hurd with working gcc.
EDIT:
gcc works now, pacman not.
Last edited by Giselher (2010-03-14 17:29:12)
Offline
Offline
Thanks for the updates.
About your broken pacman, I would need the config.log to see whats wrong there. pacman beeing linked to libc.so.6 is definatly wrong though It looks as if you compiled something along the road to pacman outside of the cross-compilation environment.
Offline
Thanks for the updates.
About your broken pacman, I would need the config.log to see whats wrong there. pacman beeing linked to libc.so.6 is definatly wrong though It looks as if you compiled something along the road to pacman outside of the cross-compilation environment.
Yupe, that was the reason, i compiled hurd form scratch again and it works now.
---
If i cannot build perl by myself i will try the debian binaries.
At the moment i get this errors:
/home/alexander/workplace/archhurd/cross/lib/gcc/i586-pc-gnu/4.4.3/../../../../i586-pc-gnu/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
make[1]: *** [generate_uudmap] Error 1
Last edited by Giselher (2010-03-15 19:16:18)
Offline
I have a working perl interpret. Yes its only microperl, but it should work.
Here is the package:
microperl-5.10.1-1-i586.pkg.tar.xz
Last edited by Giselher (2010-03-16 11:18:24)
Offline
Nice, I hope microperl will be enough for now, but perl shouldn't be that big of a problem and it is a definite must have.
On something unrelated, I believe only gnumach needs to be built for i586 everything else seems to work fine with march=i686 so I will be making the packages for i686 now. Now I was thinking what is the better choice for the arch value, 'i686' or something like 'i686-hurd'?
Also we should maybe start moving discussions to the archhurd mailing list, it would be more convinient than one large thread. I will post the arch value question on the list too, so if you have any suggestions answer there if possible
Offline