gmane.org.netlabs.libc.user

Built grep 2.5.3 successfully, or not?

John Small — 2008-11-11T13:45:01

In my continuing efforts to figure out how to port software I keep trying new source code packages to see if I can get anything to build. Most end in failure and I have not been able to figure out if the problem is - my build environment (Smedley's) - am I missing something? - do I have the wrong version of something? - which shell should I be using? - do I have all the necessary env. vars. set correctly? - my configuration - which options, if any, should I be passing to the configure scripts? - which "can't find" messages during configure are acceptable and which ones indicate an error which needs to be fixed. - which "checking for/whether xyz... no" messages during configure are acceptable and which ones indicate an error which needs to be fixed. - the source code itself - are there changes necessary to make it build under/for OS/2? I finally ran across some source which may have built successfully, grep-2.5.3 (): - running the configure script completes without any obvious-to-me, fatal errors - running "make" completes without any obvious-to-me, fatal errors But then when I run "make check" I get some failures. I see many "FAIL" messages but at the end the summary says: 3 of 13 tests failed (1 tests were not run) (I think the discrepancy (3 vs. many) comes from the fact that there were errors detected in 3 of the 13 shell scripts which were run during "make check". But several of these scripts attempt multiple tests, many of which are failing.) Early in the "make check" process it says: Please, do not be alarmed if some of the tests failed. Report them to gnu.org> How do I determine if my test failures are ones - which I should "not be alarmed" about; or - which need to be fixed before I consider the program "ready for prime time"? I am hesitant to report my failures to gnu.org because I am afraid my failures are due to self-inflicted, rookie mistakes. I am also hesitant to post the log of "make check" without being asked to do so because of its length. Any help will be greatly appreciated!

buildenv problem

Robert Blair — 2008-10-31T05:28:18

This is my first time trying to port a unix program to eCS. I started by downloading the GCC compiler but what I downloaded was not complete so I downloaded Paul Smedley's buildenv_20071022.zip. I installed AUTOCONF and GLIBIDL335 from eCS CD 2 and changed GCC335.cmd to match my system. From the readme file I ran ash ./configure and make. When I run ./configure I get the following errors type: No such file or directory type: No such file or directory type: No such file or directory type: No such file or directory function: No such file or directory builtin: No such file or directory I can not find type, function, or builtin. I run "make" and get the following errors flipit.c:89:18: pasting "SYSCONFDIR" and ""/flipit.conf"" does not give a valid preprocessing token flipit.c:89:31: pasting "SYSCONFDIR" and ""/flipit.conf"" does not give a valid preprocessing token flipit.c:159:25: pasting "SYSCONFDIR" and ""/flipit.conf"" does not give a valid preprocessing token which I assume is because configure did not run correctly. Any suggestions on what I need to do to fix the problem?

GCC 4.3.2 updated (2008-10-25)

Paul Smedley — 2008-10-25T08:45:45

Hi All, Yet another update. Major change is that Most of binutils 2.16.1 is included (with the exception of ld.exe) and that a problem with recursive threads with libstdc++ is fixed (Thanks Yuri for the patch). Download URL: http://download.smedley.info/gcc-4.3.2-os2-20081025.zip Patches URL: http://download.smedley.info/gcc-4.3.2-os2-20081025-patch.zip

GCC 4.3.2 news - Firefox builds!

Paul Smedley — 2008-10-08T08:40:43

Hi All, I managed to get some form of dllexport support working in GCC 4.3.2 today, and successfully built Firefox 3.0-cvs using it (http://smedley.info/mozilla.jpg) It required just a couple of extras changes above those required to build using 3.4.6 There are still known issues with my current GCC 4.3.2 build: - precompiled headers do not currently work - no thread support in gcc.exe as I forgot to --enable-threads when running configure - this will be fixed in the next drop - for some strange reason, gcc fails to produce an executable where there are libs added on the command line that are not required, ie gcc -Zexe -Zomf -s conftest.c -lgccFAILS gcc -Zexe -Zomf -s conftest.c WORKS - no support yet for the GOMP multiprocessor library - link warning when using -Zomf - emxomf will require updating to deal with the new stabs types, but according to Knut, the warnings can be safely ignored This build hasn't had huge amounts of testing, but has been used to build Scribus, Firefox 3.0cvs and ffmpeg successfully. Any feedback on things that work/don't work vs GCC 3.3.5 would be appreciated! The binary itself can be downloaded from http://download.smedley.info/gcc-4.3.2-os2-20081008.zip Please also keep checking http;//os2ports.smedley.info for newer builds. Feedback appreciated :)

Port of GCC 4.0.4 available

Paul Smedley — 2008-10-03T10:14:54

Hi All, A preliminary port of GCC 4.0.4 is now available. Seems to do most of the things that GCC 3.4.6 can do - EXCEPT build Mozilla - that fails build javascript with some 'declaration of C function xxxxx conflicts with previous declaration yyyyyyy' errors to do with js_static_assert that I need to investigate. Binary & patches available from http://www.smedley.info/os2ports/index.php?page=gcc

Smedley's build environment questions

John Small — 2008-09-25T12:20:59

Over the years I have made several attempts to get a well-functioning GCC build environment working. These attempts have met varying levels of success. Various recent threads on these newsgroups (regarding the Mozilla build env, the possibility of support for GCC 3.4.x, etc.) have revived my interest in this. I have downloaded Paul Smedley's build environment and I have unzipped it onto an otherwise empty U: drive and I have followed the instructions regarding running makeomflibs and setting up an icon. Now I have many questions: 1) Is this the best forum for such questions? Or are others which may also be helpful? 2) The web page only refers to running MAKEOMFLIBS in the extras\lib directory while the readme says to do this in both extras\lib and usr\lib. Which is correct? 3) Since I unzipped to the U: drive, are there any adjustments which need to be made to set up the build environment correctly? I ask because... a) My global environment does not set EMX, GLIB, LIBIDL, TOOLKIT, AUTOCONF and VACPP365. GCC335.CMD proceeds to set these to default but non-existent directories/files. Is this OK? Or should some or all of these have valid settings? b) GCC335.CMD sets some other variables in ways that lead to questions about their correctness: i) TERMCAP, GLIB_CONFIG and LIBIDL_CONFIG: Are set to point to non-existent directories/files because of the errors in environment variables due to (a) above. ii) TERM: Is not set. Why TERMCAP but not TERM? iii) LIB: Uses forward slashes on the first directory and backslashes on the rest?? c) U:\moztools\config.site-gcc335b4 has a number of hard-coded paths. Which ones, if any, need to be corrected to point to actual files/directories before the "environment" is minimally correct? d) Are there restrictions on the paths used in these various settings? i) Which need to be on the same drive (i.e. U:)? And which can be on other drives? ii) Which must not have a drive letter and colon? iii) Which need forward slashes, which need backslashes, which don't care and is it ever OK to have some of each (See b.iii above)? 4) Is there a test package somewhere which I could try to build which is "basic" enough to test the essential functionality of Paul's build environment? I have tried (and failed) builds of less-381 and pcre-6.7. Less-381 almost builds (there is a problem with "___open" : unresolved external). The pcre-6.7 fails with "LIBTOOL< at >: Can't open LIBTOOL< at >", which I assume means I need libtool. (Is this a symptom of a flaw in the environment?) 5) Some packages come with a makefile purported to be the makefile for OS/2 (makefile.o2e). But they seem to be quite old in comparison to the dates of the source files. Are these worth trying? These are but a few of the questions I have. Thanks for reading this far and thanks for any help you can provide!

Can I set OS/2 native attributes with libc?

Steven Levine — 2008-09-13T20:53:49

Hi, I'm adding native file attribute support to rsync (i.e. FILE_HIDDEN etc.). chmod() does not currently support modifying these attributes. Is there a similar function that does? I can always write my own routines for this, but I prefer to avoid reinventing the wheel. Thanks, Steven

Building GCC 3.4.6

Paul Smedley — 2008-09-13T09:55:08

Rough instructions - hopefully I haven't missed anything major.... 1) Download gcc-core-3.4.6.tar.bz2 & gcc-g++-3.4.6.tar.bz2 from your favourite GNU mirror and extract 2) Download: http://download.smedley.info/gcc-3.4.6-os2-patch.zip and extract into the gcc-3.4.6 directory 3) patch the source using the supplied gcc-3.4.6.patch (ie patch -p1 < gcc-3.4.6.patch) 4) Run ./configure using parameters something like: ash ./configure --enable-threads --enable-shared --enable-languages=c,c++ 5) make sure gcc-3.4.6\gcc is in the path - otherwise alter on xgcc will complain about not being able to find cc1.exe 6) Run make 7) You'll probably get an error about libstdc++ not being able to find attribute.cc - copy libstdc++\src\*.cc into i386-pc-os2-emx\libstdc++\src 8) Rerun make Should complete now - make install will copy all files into \usr\local (unless you specified an alternative directory in 4) above Any feedback appreciated on building this - and of course patches appreciated too to fix problems :)

GCC 3.4.6 build available

Paul Smedley — 2008-09-12T05:59:59

Hi All, Anyone who also reads the Mozilla OS2 newsgroup may be aware that I've been exploring GCC 3.4.6 in recent weeks. Finally, I have something that I feel is ready for public consumption! The binaries can be downloaded from: http://download.smedley.info/gcc-3.4.6-os2-20080912.zip (7,933,439 bytes) There is currently no sample gccenv.cmd included in the package, but a setmozenv.cmd based on the one for GCC 3.3.5 is available from http://download.smedley.info/setmozenv_gcc346.cmd Note that the gcc .zip installs itself in u:\usr\local\bin and won't interfere with an existing gcc 3.3.5 install in u:\usr\bin I've successfully built a bunch of stuff with this, so I'm very interested in any feedback!

git ?

Brendan Oakley — 2008-09-05T00:12:31

Hi guys, No sooner does Andrew have Mercurial ported, than ALSA switches from Hg to git. (Oh the irony.) I'm not in any particular hurry, just wondered if anyone else had interest or had looked at it? Thanks. Brendan

wxDEPRECATED trouble

2008-08-30T14:20:24

Addressed to: wx-dev< at >lists.wxwidgets.org libc-user< at >netlabs.org Hi, wxDEPRECATED is giving me "interesting" trouble with gcc-3.3.5 on OS/2. IMHO, it really sounds like a compiler error, but if so, it's probably going to be hard to track it down, so for now, I do need a workaround... It's working mostly fine, just in one file (image.h) wxDEPRECATED is causing a parse error... If I follow string.h's lead (where it's "working" just fine) and replace e.g. wxDEPRECATED( bool LoadFile(const wxString& name, long type, int index = -1) { return LoadFile(name, (wxBitmapType)type, index); } ) by wxDEPRECATED(inline bool LoadFile(const wxString& name, long type, int index = -1)); inline bool LoadFile(const wxString& name, long type, int index = -1) { return LoadFile(name, (wxBitmapType)type, index); } then the compiler gives error messages like: ./../include/wx/image.h:481: error: `bool wxImage::LoadFile(const wxString&, long int, int)' and `bool wxImage::LoadFile(const wxString&, long int, int)' cannot be overloaded Even more confusing, If I take one such inlined & deprecated function from wxString and add it to wxImage by copy and paste, so I have e.g. an inlined wxImage::Strlen(const char *psz), I get the same kind of "cannot be overloaded" error, although the exact same lines compile fine for wxString. ATM, I'm a bit out of "nice" ideas what to do to make it compile, the two "ugly" ideas I've left are to either completely "disable" wxDEPRECATED in defs.h for OS/2 port of gcc or to add something like #if wxCHECK_GCC_VERSION(3, 1) && defined(__EMX__) #undef wxDEPRECATED #define wxDEPRECATED(x) x #endif at the beginning of the WXWIN_COMPATIBILITY_2_8 section of image.h (and possibly revert it at the end of that section, so we at least still get all the deprecation warnings from all the other classes. I think I slightly prefer the second, even though the resulting code modification is even uglier... Any other ideas? Regards, Stefan

open access mode problem

Guerreiro Philippe — 2008-08-27T14:13:29

Hello, testing this simple program : // Test #include #include #include // main(int argc, char *argv[], char *envp[]) { struct stat s; int fd; fd = open("eec.txt",O_RDWR|O_CREAT, 0666); fstat(fd, &s); printf("%d", s.st_mode & 0777); return; } I have the following results : on HPFS, JFS and FAT16 : "420" (0644 in octal) on FAT32, VMMAP (VirtualPC shared folder) : "438" (0666 in octal) Somebody can tell me why there are differences ? Thanks

Mercurial v1.0.2 port available

Andrew MacIntyre — 2008-08-23T02:54:19

I've made available a port of the Mercurial SCMS available from my website (see .sig) - it is listed on the "Packages" (aka "Other ports to OS/2") page. The binary release requires the EMX port of Python 2.4.4, also available from my website. Peter Weilbacher and Dave Yeo have been playing with pre-releases, and I thank them for their feedback. There are a couple of issues to be aware of: - binary vs text stdin/stdout/stderr streams - choice of editor for commit messages - TZ environment variable - line ending management The first 3 issues are addressed in the README; the fourth is still clarifying... I don't plan to put this up on Hobbes just yet, as there may still be a brown paper bag release or two to come... While I can't help much with actually using Mercurial, but I do want to hear about any failures or unexpected behaviour. By all means forward this announcement to other OS/2 developement fora. Have fun, Andrew.

_fsetmode() vs setmode()

Dave Yeo — 2008-08-02T04:47:04

To set stdin/stout to binary is setmode() good enough, eg something like setmode (fileno (stdout), O_BINARY); or do we still have to do _fsetmode(stdout, "b"); Dave

[kLIBC] #199: libc: the ctype.h is_whatever doesn't handle EOF correctly / busted char 255 in setlocal

kLIBC — 2008-07-11T00:11:19

#199: libc: the ctype.h is_whatever doesn't handle EOF correctly / busted char 255 in setlocal --------------------+------------------------------------------------------- Reporter: bird | Owner: bird Type: defect | Status: new Priority: normal | Milestone: libc-0.6.4 Component: libc | Version: 0.6.2 Severity: normal | Keywords: Blocking: | Blockedby: --------------------+------------------------------------------------------- See conversation with Peter.

[kLIBC] #198: libc: utimes doesn't handle dates prior to 1980 in a good manner

kLIBC — 2008-07-11T00:10:17

#198: libc: utimes doesn't handle dates prior to 1980 in a good manner --------------------------+------------------------------------------------- Reporter: bird | Owner: bird Type: defect | Status: new Priority: normal | Milestone: libc-0.6.4 Component: libc-backend | Version: Severity: normal | Keywords: Blocking: | Blockedby: --------------------------+------------------------------------------------- Seems to be wrapping or something now, we should either return a failure or just stop at 1980.

behaviour of utime()/utimes()

Andrew MacIntyre — 2008-07-09T13:58:56

In looking at getting Mercurial running, I've got to the point of all bar one test passing on my EMX build of Python (with an extension module that wraps (the EMX setmode() & _fsetmode() functions). The failing test is due to the access/modification times not round-tripping, ie what's set with utime() is not being returned by stat(). I wrote a short C test to confirm the behaviour as an EMX runtime/C library issue, which it appears to be. Not being keen to invest time in trying to solve the issue in EMX, I tried my C test with gcc 3.3.5/libc063. This shows the same problem, but worse, the creation time is modified as well as the access and modification times. In both libc063 and EMX builds, modifying the test program to use utimes() rather than utime() results in the same behaviour. My utime() test program: ---8<---8<---8<--- #include #include #include #include #include #include int main(int argc, char *argv[]) { struct utimbuf tm_buf; struct stat st_buf; int rc; char fname[20] = "test.dat"; rc = stat(fname, &st_buf); if (!rc) { fprintf(stdout, "before: atime = %ul, mtime = %ul, ctime = %ul\n", st_buf.st_atime, st_buf.st_mtime, st_buf.st_ctime); } else { perror("stat()"); return rc; } tm_buf.actime = 1000; tm_buf.modtime = 1000; rc = utime(fname, &tm_buf); fprintf(stderr, "utime(): rc = %d\n", rc); rc = stat(fname, &st_buf); if (!rc) { fprintf(stdout, "after: atime = %ul, mtime = %ul, ctime = %ul\n", st_buf.st_atime, st_buf.st_mtime, st_buf.st_ctime); } else { perror("stat()"); return rc; } return rc; } ---8<---8<---8<--- test.dat I created with touch, and used touch before each test run. EMX results: before: atime = 1215611254l, mtime = 1215611254l, ctime = 1215517052l utime(): rc = 0 after: atime = 4039337800l, mtime = 4039337800l, ctime = 1215517052l gcc335/libc063 results: before: atime = 1215611318l, mtime = 1215611318l, ctime = 1215611318l utime(): rc = 0 after: atime = 4039373800l, mtime = 4039373800l, ctime = 4039373800l The time actually set, by both builds, is 1/01/98 10:16, rather than the intended 1/1/70 10:16. I don't know the underlying OS/2 capabilities well enough to know whether a 1970 date can be set, but the EMX library docs don't note any such limitations for utime() or utimes(). BTW, the machine is running Warp 4, FP12 if that matters (haven't got around to updating to eCs 1.2R...). Thoughts?

isalpha(EOF)

Peter Weilbacher — 2008-07-04T00:11:01

While investigating https://bugzilla.mozilla.org/show_bug.cgi?id=442210 we traced the problem to how GCC 3.3.5 handles isalpha if the argument is EOF. Brendan Eich said This reminds me of broken Unix libc ports to odd systems. Since c is int, EOF is -1 (check this in your stdio.h). Then you need to offset the attributes lookup table it uses for isspace, etc., by 1, so indexing by -1 is memory safe and gets the right (0) attrs for EOF. I'm not really sure if I fully follow him. But it seems that we have a problem with isalpha(EOF) with GCC 3.3.5 that makes us behave non-standard somehow. FWIW, isalpha(c) preprocesses to __istype((c), (0x00010000U)) with GCC 3.3.5 while it did to __istype((c), (0x0001)|(0x0002)) with GCC 3.2.2 which still showed the correct behavior... Any ideas what I should try to do to ctype.h or _ctype.h? Peter.

Patch level for libc063-cds3 incorrect

James Moe — 2008-06-02T18:09:58

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, The patch level for libc063-csd3 is incorrect. It proclaims that libc is 0.6.2 while everything else says 0.6.3. Here is what I found for libc063-csd3 using "gcc --verbose test.c": __KLIBC__ = 0 __KLIBC_MINOR__ = 6 __KLIBC_PATCHLEVEL__ = 2 __KLIBC_VERSION__ = 0x00060002 See <.../usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5/specs>, the "*predefines" section. - -- jimoe (at) sohnen-moe (dot) com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (OS/2) iD8DBQFIRDd2zTcr8Prq0ZMRAh3kAKCyb08fpygU9H2Vn0tcode0KNcGgQCbB+rM NcRyQharQ7pg5gZxRURBOoY= =2f+T -----END PGP SIGNATURE-----

[kLIBC] #197: isatty() doesn't return zero for named pipe handle

kLIBC — 2008-05-24T17:09:20

#197: isatty() doesn't return zero for named pipe handle --------------------+------------------------------------------------------- Reporter: guest | Owner: bird Type: defect | Status: new Priority: normal | Milestone: libc-0.6.4 Component: libc | Version: Severity: normal | Keywords: Blocking: | Blockedby: --------------------+------------------------------------------------------- From froloff isatty() function return wrong value for named pipe handle, which was inherited from parent process. It works fine for unnamed pipe handles. I didn't test isatty() behavior, if named pipe created inside the process calling this function. Tested with libc063 version.

_SC_NPROCESSORS_ONLN

Dave Yeo — 2008-05-21T14:51:55

Is _SC_NPROCESSORS_ONLN implemented in klibc? And if not is there an easy way to find out how many CPUs a process is using? Dave