Hi there, > > Looking at other symptoms I think you have not specified absolute path. > What was the exact command you run? From which directory? > Yes, my bad. It works correctly with the absolute path ;)
> > > 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 > I'm using Mint and ls -l `which sh` lrwxrwxrwx 1 root root 4 Apr 5 2013 /bin/sh -> dash After a little search I found that to avoid problems with bash scripts the shebang line should be set to #!/bin/bash (among other alternatives) so that made it. > > >> 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. > The issue was again related to the path, the script sets the HSCT_HOME in a relative way and not in an absolute. By setting HSCT_HOME=$PWD it works, although I don't know if this can bring problems with other packages. > > 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. > > All in all, shame on me, the script is working. I made an attempt to write a HARBOUR for libpng, this is what the build function looks like shipname=libpng shipversion=1.6.10 shipsources=" ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng16/${shipname}-${shipversion}.tar.gz " build() { run tar xzf "${shipname}-${shipversion}.tar.gz" cd "${shipname}-${shipversion}" run env \ CC="$HSCT_CC" \ CFLAGS="$HSCT_CFLAGS $HSCT_LDFLAGS_FOR_CC" \ LD="$HSCT_LD" \ LDFLAGS="-L/home/esteban/helenos/coastline/dist/zlib/lib"\ ./configure run make } The configuration process ends correctly but the testing executable 'testpng' isn't built for HelenOS but for my system. I'm not quite sure why is this happening. In the big picture, what I'm trying to do is to generate the static library so then I copy it along with the corresponding header file into the right directories in the source tree of the OS. A good way of testing should be by trying to compile something from the OS itself. Is this something possible right now? 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 > >
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
