Hi Esteban. 2014-03-05 17:54 GMT+01:00 Esteban Campostrini <[email protected]>:
> Hi Vojta, > > I returned to the coastline. The first problems that I ran into seem to be > related to > the paths. The first one was related to the identification of the > architecture done by the hsct.sh, it wasn't > able to do it, it would complain when trying to initialize and build the > image of HelenOS printing: > > >>> Initializing this build directory. > -> Cleaning previous configuration in /home/esteban/helenos/mainline. > -> Configuring for ia32. > Fetching current revision identifier ... ok > -> Building (may take a while). > -> Generating the configuration file. > >>> Caching headers, libraries and compile flags > [hsct]: Error: Unsupported architecture: $(UARCH) = ''. > Looking at other symptoms I think you have not specified absolute path. What was the exact command you run? From which directory? > I solved temporarily that by hardcoding the architecture by setting: > HSCT_UARCH="ia32" > It happened the same with the script that fetches the location of the > linker, and again > I temporarily hardcoded it to: > _LINKER_SCRIPT="../mainline/uspace/lib/c/arch/ia32/_link.ld" > I did the same with the line 367 (the section that copies the headers) > since it uses HSCT_UARCH: > cp -L -R > "$HSTC_HELENOS_ROOT/uspace/lib/c/arch/$HSCT_UARCH/include/libarch/" > "$HSCT_CACHE_DIR/include/" > Again, this looks to me like some relative vs. absolute path problem. > After those modifications the script builds the image without complaining. > The image boots and seems to run OK. > > The next step is building the desired app. Since I'm using bash instead of > sh I had to change the first line > of the script to call bash (#!/bin/bash.) > I do not know which distro you use, but it is quite common, that ls -l `which sh` lrwxrwxrwx 1 root root 4 25. srp 2013 /usr/bin/sh -> bash > > After all these changes I could build zlib and install it, all through the > script. I remade the image of the SO and > executed minizip with textdemo and it produced the expected output. > Cool :-). Good job. > > I tried with libgmp and this is the output I got: > > esteban@satellite ~/helenos/coastline $ ./hsct.sh build libgmp/ > >>> Caching headers, libraries and compile flags > -> Copying linker script and startup object file > -> Copying libraries > -> Copying headers > -> Fixing includes in libc headers > -> Saving config files > -> Copying extra headers and libraries > -> Fixing compiler flags > >>> Fetching sources... > -> Fetching gmp-5.1.0.tar.bz2... > --2014-03-05 13:49:00-- > ftp://ftp.gmplib.org/pub/gmp-5.1.0/gmp-5.1.0.tar.bz2 > => `/home/esteban/helenos/coastline/sources/gmp-5.1.0.tar.bz2' > Resolving ftp.gmplib.org (ftp.gmplib.org)... 37.252.124.96 > Connecting to ftp.gmplib.org (ftp.gmplib.org)|37.252.124.96|:21... > connected. > Logging in as anonymous ... Logged in! > ==> SYST ... done. ==> PWD ... done. > ==> TYPE I ... done. ==> CWD (1) /pub/gmp-5.1.0 ... done. > ==> SIZE gmp-5.1.0.tar.bz2 ... 2194942 > ==> PASV ... done. ==> RETR gmp-5.1.0.tar.bz2 ... done. > Length: 2194942 (2.1M) (unauthoritative) > > 100%[==============================================================================================================================>] > 2,194,942 171K/s in 18s > > 2014-03-05 13:49:22 (118 KB/s) - > `/home/esteban/helenos/coastline/sources/gmp-5.1.0.tar.bz2' saved [2194942] > > >>> Building... > [hsct]: "tar" "xjf" "gmp-5.1.0.tar.bz2" > >>> Patching gmp.h... > ./libgmp//HARBOUR: line 38: gmp-h.patch: No such file or directory > [hsct]: Error: Build failed! > ./hsct.sh: line 917: leave_script_err: command not found > Again: absolute path? By the way, which version of coastline are you using? Current master (cddf875) has only 912 lines. If specifying the absolute would not help, please, send a brief description of the directory layout you use (i.e. where is HelenOS checkout, where is coastline clone and where you build) and maybe also some version info about your system (Bash, GCC, ...). If the relative path was the culprit, I will try to fix the script to handle this situation properly. Thanks for the update. Cheers, - Vojta > I tried to execute the patch command by hand and I got the same error. > > Anyway, there was some progress yay! =P > I think I'll try to create a HARBOUR for libpng, and keep investigating on > the 'patch' error. If > you have a clue of what can it be I'll be thankful. > > Cheers, > Esteban > > > > 2014-03-05 4:13 GMT-03:00 Vojtech Horky <[email protected]>: > > Hi Esteban. >> >> 2014-03-04 16:37 GMT+01:00 Esteban Campostrini <[email protected]>: >> >> Hi all, >>> >>> Thanks Martin for the answer. Right now I'm trying to port a static >>> library which I think involves a similar procedure >>> to the one needed to export an app. >>> Based on Vojta's blog on how to port apps I'm trying to start porting a >>> static version of zlib and then a static >>> version of libpng. I started using the coastline but it gives some >>> errors, so since >>> >> Can you, please, be more specific? What commands have you run? Was it >> error message from coastline scripts or a failure during the build process? >> >> >> >>> the porting of zlib >>> should be fairly simple (I'm doing it for ia32) I resorted to the >>> previous script (i.e. configure-for-helenos.sh.) >>> >> Ok, but please, be aware that I no longer update this script and that >> coastline offers much better environment (packaging, installation into >> HelenOS source tree etc.). >> >> >> The thing is that when I execute the make, after invoking the script with >>> the proper arguments (the ones >>> from the blog), it gives me the following error msg: >>> >>> /usr/local/cross/ia32/lib/gcc/i686-pc-linux-gnu/4.8.1/../../../../i686-pc-linux-gnu/bin/ld: >>> example: could not find output section .gnu.version_r >>> >> Looks to me that you are not using correct linker script. Can you, >> please, post a complete output? Especially the output from ./configure and >> some context before this error occurred. >> >> I am aware that the documentation for porting software to HelenOS is >> rather minimalistic at the moment. I started a new wiki page [1] but I am >> not sure when I will find enough time to write a thorough guide. So, right >> now there are only links to existing resources. New paragraphs/comments are >> welcome :-). >> >> Cheers, >> - Vojta >> >> [1] http://trac.helenos.org/wiki/PortingSoftware >> >> >> >>> It looks like something is missing. Could you give me a hint on what can >>> it be? >>> >>> Thanks in advance. >>> >>> Cheers, >>> Esteban >>> >>> >>> >>> >>> 2014-03-03 11:33 GMT-03:00 Martin Decky <[email protected]>: >>> >>> Hello Esteban, >>>> >>>> >>>> Since I'm new at porting code I have a couple of questions: >>>>> The idea would be 'rewrite' the code in order for it to use the subset >>>>> of C supported by HelenSO right? >>>>> >>>> >>>> If such changes would be minimal and well contained (e.g. in a rather >>>> small patch that could be applied automatically on the upstream sources), >>>> changing the upstream source tree is fine. On the other hand, you probably >>>> don't want to fork a wildly diverge the upstream libpng. Having such a >>>> diverged libpng would be of little benefit compared to writing our own PNG >>>> library. >>>> >>>> If you expect the required changes in libpng to be substantial, you >>>> should choose the other path -- extend the HelenOS native libc or the >>>> libposix compatibility library by functions that are required by linpng. >>>> >>>> Generally speaking it is really a matter of taste whether you prefer >>>> changing the ported library or extending the environment. But the ultimate >>>> goal should be the same in both cases: A clean and well-designed solution. >>>> >>>> >>>> In that case I have another doubt, the library contains some files >>>>> which easily exceed the 3K lines. This kind of task is generally done >>>>> by >>>>> inspecting line by line or some kind of automation can be achieved? >>>>> >>>> >>>> The basic automation is based on link-time checks. If the library can >>>> link with the environment (libc, libposix), there is a reasonable chance >>>> that the environment will behave with respect to the library as expected >>>> (although there might be subtle differences, especially in corner cases >>>> (*)). You should use the test suite of libpng then to check for the >>>> behaviour compliance. >>>> >>>> If these automated steps fail you would have to resort to manual >>>> inspection of the code. >>>> >>>> (*) HelenOS is not POSIX compliant. Even the libc functions that have >>>> POSIX-similar names are not guaranteed to behave in a POSIXly compliant way >>>> (but they should behave reasonably). Even the functions in libposix are not >>>> guaranteed to be 100% POSIX compliant (since they might be unfinished). The >>>> keyword is "best effort" :) >>>> >>>> >>>> M.D. >>>> >>>> >>>> _______________________________________________ >>>> HelenOS-devel mailing list >>>> [email protected] >>>> http://lists.modry.cz/listinfo/helenos-devel >>>> >>> >>> >>> _______________________________________________ >>> HelenOS-devel mailing list >>> [email protected] >>> http://lists.modry.cz/listinfo/helenos-devel >>> >>> >> >> _______________________________________________ >> HelenOS-devel mailing list >> [email protected] >> http://lists.modry.cz/listinfo/helenos-devel >> >> > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/listinfo/helenos-devel > >
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
