headers
Steven Levine | 20 Apr 05:41
Picon
Favicon
Gravatar

Building libc064x - unexpected undefined externals


Hi,

I'm back to building libc064 from the branch and everything is fine until
it's time to link libc064x.dll.  This fails with are large number of
undefines of the form

weakld: error: Unresolved symbol (UNDEF) '_getlogin'.
weakld: info: The symbol is referenced by:
    I:\sla_dev2\libc-0.6-branch\emx\out\dbg\omf\libc_s.lib(glob.obj)
weakld: error: Unresolved symbol (UNDEF) '_memcmp'.

I have the fixes from ticket #222 installed.  Do I need something else?

The toolchain is gcc445 and ilink, but I'm willing to use something else
if that is required.

FWIW, my build of emxomfld from the branch seems to have issues.  When
building rsync 3.0.8, with gcc 3.5.2, emxomfld fails claiming it can't
find the symbol named ''. Reverting to an older emxomfld resolves the
error.  The failure appears to be specific to a single .o file.  There are
no problems building rsync 3.0.7 which does not differ all that much from
3.0.8.  I'll provide a testcase once I am sure it's not something wrong
with by libc build setup.

Thanks,

Steven

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Yeo | 11 Apr 02:04

Response files

Should GCC and emxomfld accept response files? eg gcc @file or emxomfld 
@file.
We're having a problem with Mozilla where they've changed their build 
system to link all the object files into xul.dll instead of static libs 
and the linking stage ends with g++: error trying to exec 
'emxomfld.exe': execvp: Invalid argument.
A build log is here, 
https://bug648134.bugzilla.mozilla.org/attachment.cgi?id=524988
Dave
Permalink | Reply | 1 comment |
headers
Steven Levine | 30 Dec 23:16
Picon
Favicon
Gravatar

What svn changeset corresponds to libc063.dll?


Hi,

Based on the file date, it would appear that trunk changeset 3514 should
match the libc063 binary.  However, this is not the case.  I need to go
bad to changeset 2733 in some cases to match the sources with the binary.

There don't not seem to be any useful tags or branches that match up
either.

Does anyone know what the situation is and what changeset I really should
be using?

Thanks,

Steven

--

-- 
----------------------------------------------------------------------
"Steven Levine" <steve53 <at> earthlink.net>  eCS/Warp/DIY etc.
www.scoug.com www.ecomstation.com
----------------------------------------------------------------------
Permalink | Reply | 2 comments |
headers
KO Myung-Hun | 18 Aug 18:25

Exception bug on gcc 4.3.x and 4.4.x

Hi/2.

I've seemed to encounter an exception bug. The 'catch' block of the
attached codes does not work.

EMX and kLIBC 3.3.5 works as expected.

But gcc 4.3.x and 4.4.x terminated with SIGABRT as the following.

-----
terminate called after throwing an instance of 'char const*'
terminate called recursively

Killed by SIGABRT
pid=0x035c ppid=0x0357 tid=0x0001 slot=0x00b2 pri=0x0200 mc=0x0001
F:\LANG\WORK\TEST\XS.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
-----

--

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.0.3
Under OS/2 Warp 4 for Korean with FixPak #15
On Intel Core2Duo T5500 1.66 GHz with 1 GB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr


(Continue reading)






Permalink
| Reply
| 2 comments  
| 



  

  

  





headers


BERTRAND Joel
 | 
11 Aug 13:47






Picon





semget() fails


	Hello,

	I don't know if my message was posted on the mailing list because I 
haven't received it. I beg you pardon if you have received it twice...

Original post :

     Hello,

     I have written a library that emulates Poxis semaphores with 
SystemV ones. To do that, I have used semget() function that always fails.

Configuration : eCS 2.0 + EMX 0.9d, gcc-4.4.4 (and all GNU tools).

Source code :

#ifndef UNION_SEMUN
union semun
{
     int                 val;
     struct semid_ds     *buf;
     unsigned short      *array;
     struct seminfo      *__buf;
};
#endif

int
sem_init_SysV(sem_t *semaphore, int shared, unsigned int valeur)
{
     int             ios;

(Continue reading)






Permalink
| Reply
| 4 comments  
| 



  

  

  





headers


joel.bertrand
 | 
11 Aug 12:35






Picon





semget() always fails


	Hello,

	I have written a library that emulates Poxis semaphores with SystemV 
ones. To do that, I have used semget() function that always fails.

Configuration : eCS 2.0 + EMX 0.9d, gcc-4.4.4 (and all GNU tools).

Source code :

#ifndef UNION_SEMUN
union semun
{
     int                 val;
     struct semid_ds     *buf;
     unsigned short      *array;
     struct seminfo      *__buf;
};
#endif

int
sem_init_SysV(sem_t *semaphore, int shared, unsigned int valeur)
{
     int             ios;

     union semun     argument;

     if (shared != 0)
     {
         return(ENOSYS);
     }

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Galen Henderson
 | 
25 Mar 21:49





mmap?


Hello all.  I am trying to build harvest using my setup of Paul's 
build environment and GCC 442.  It requires mmap.  I was wondering if 
there was any architectual limitation or something that would prevent 
mmap files from working on ECS/OS/2?  Before I go on a wild goose 
chase for headers and libs and such, I thought I would check here with
the experts first.  Any ideas?

--

-- 
Regards,
Galen
------
There are only 10 kinds of people in the world.  Those who understand 
binary and those who don't.






Permalink
| Reply
| 3 comments  
| 



  

  

  





headers


Anton Monroe
 | 
8 Nov 22:24





Unix EAs


This is a follow-up to a thread I started last January about Unix EAs.
The problem I had was that a kLibc version of unzip.exe created files
with a lot of Unix EAs. I not only didn't need them, but they prevented
DOS apps from reading the unzipped files.

On the Netlabs bug tracker, I found tickets #21 and #206 where Knut
mentioned the possibility of using an environment variable to control
if and where Unix EAs are used. Currently, it uses Unix EAs on HPFS,
JFS, FAT, and RAMFS drives.

So I decided to try hacking kLibc to suit myself. Not being a real
programmer, I had a few problems putting together a build environment.
But now I can finally do "make double-quick" in the libc-0.6 directory
with only a couple of errors. Lots of warnings, but that may be normal.
I hope.

The attached patch is what I have so far. It removes the critical flag
from the Unix EAs, and also provides for an environment variable called
LIBC_UNIXEA_DRIVES which overrides the defaults. That way I can have
Unix EAs and symlinks on my NDFS drives, or prevent unzip from creating
Unix EAs with "set LIBC_UNIXEA_DRIVES=*-". I don't know if this is what
Knut had in mind, but it works for me.

I have to write with a copy of "Teach Yourself C" in one hand, so there
is a very good chance I did something dumb or dangerous.  Any comments? 
Yeah, I know this list isn't a beginner's C class, but someone here
might be interested. 

Anton


(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Paul Smedley
 | 
25 Jul 11:58






Picon





GCC 4.4.1 now available


Hi All,

Per the subject - 
http://download.smedley.info/gcc-4.4.1-os2-20090725.zip

Firefox builds now work ok for me.

List of GNU changes is at 
http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution
=FIXED&target_milestone=4.4.1

--

-- 
Cheers,

Paul.






Permalink
| Reply
| 2 comments  
| 



  

  

  





headers


Dave Yeo
 | 
3 Jun 05:26





Re: Mercurial 1.0.2


On 08/21/08 07:54 am, Andrew MacIntyre wrote:
> Attached are the binary installation package for the Python 2.4.4 EMX
> port and the source patches archive for Mercurial 1.0.2.
>
...
> If you spot any issues, please get back to me ASAP.
>

Interesting issue, I just applied a patch with Mercurial, made a typo 
and typed .dif instead of .diff, Mercurial completed the patch name and 
applied it, nice issue :)
Also as noted in coopp (os2 programming porting) newer tee's such as 
version 5.94 correctly set text mode on the console so piping the hg 
output through tee gives nice output in a vio session. I understand the 
4os2 tee is the same.
Dave






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Alex Taylor
 | 
30 May 02:29





setlocale() and codepage (3.3.6)


Using GCC 3.3.6, I don't know if this applies to later versions...

Calling
  char *loc = setlocale(LC_TIME, "")
is supposed to set the time conventions to the current locale defined in
the environment, which it does.

However, it seems to automatically append the codepage specifier ISO8859-1,
regardless of what the current codepage is.

For instance, running under Japanese OS/2, this code:
  char *loc = setlocale(LC_TIME, "")
  printf("Locale:     %s\n", loc );

reports:
  ja_JP.ISO8859-1
which isn't very useful, as ISO8859-1 doesn't support Japanese text.  If
I then try to print a localized time string from strftime, the Japanese
characters are all replaced by 0x1A (even though the current process 
codepage supports them).  

Is there any graceful way to tell setlocale() to use the current process 
codepage?






Permalink
| Reply
| 4 comments  
| 



  

  

  

  


  





    



Gmane