• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - ydario

#1
Quote from: melf on 2012.03.10, 19:13:28
The ic*.dlls pack is missing among the zip-packages. I took them from my OO32 and that worked fine.

thanks for spotting this, I have uploaded to netlabs also the latest zip files.
#2
Quote from: David McKenna on 2012.03.10, 18:50:04
COMPHELP->CPPUH3.__ZN3com3sun4star3uno19WeakReferenceHelperaSERKNS2_9


it seems to me that it finds some other OOo dlls around.
#3
The full OS/2 source code for Apache OpenOffice for OS/2 is committed to the Apache OO incubator project,

http://svn.apache.org/viewvc/incubator/ooo/trunk/

You can grab it with

   svn co http://svn.apache.org/viewvc/incubator/ooo/trunk/

and build yourself, provided you have all the required system tools and libraries in place. Everything is available in the netlabs rpm repository.

Weekly dev builds are published here:

https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots

#4
Quote from: djcaetano on 2012.02.27, 20:42:04
  Path was: D:\PROGRAMS\OO

works for me in that location... and I don't see why it can't work either.
error 2 means that it cannot locate D:\PROGRAMS\OO\ure\bin\sal3.dll; are you sure this file is in the correct place?

you don't need to reinstall, just copy all files to d:\programs\oo
#5
Quote from: djcaetano on 2012.01.24, 01:09:45
Quote from: jep on 2012.01.20, 12:58:01
Had exaclty the same problem...
I placed the HOME and the Programs folders on D: but OpenOffice didn't start after I tried to install it to D:\Programs.
Solution:
Install it to C:
e.g. C:\Programs\OpenOffice... that is.
//Jan-Erik

  Thanks Jan. Installing to C: did the trick.
  Weird.

really weird, OOo installation does not depend on drive, I'm pretty sure ;-)

Which path did you use on  on D: ? file system?
#6
Quote from: dryeo on 2012.02.06, 09:58:21
Wish wlink worked as well for Firefox. Rich had to patch it to more aggressively to use high memory, ( http://e-vertise.com/misc/wl-fix.zip) and there are page table overflows with a debug build.
Fyi he changed the patch to use high memory for 4 k chunks instead of 64 k chunks.

To work around a problem with the OS X linker, Mozilla got rid of static libs so for FF10 there are 2411 object files passed to GCC which our GCC can't pass on to the linker due to the lack of support for writing response files. We're calling emxomfar directly. Does your gcc 4.4.6 fixes include support for such huge command lines?
Currently using the 4.4.6 port from Paul's site fails to build a useful browser. It acts the same as if there was no network connection. Is the RPM version the same version of 4.4.6? I haven't used RPM much due to bandwidth limitations.

I see XUL.DLL is bigger than SW.DLL... so probably OOo didn't touch the wlink limits...

But yes, gcc 4.4.6 makes use of response files to interact with child processes, also it does no longer use fork() to start them.
RPM and Paul's build are two builds generated from same source tree, so they are not the same binaries but I expect them to have same behaviour. The RPM one is also available with P4 code optimization.
#7
Quote from: ivan on 2012.02.05, 21:06:34
Are you saying that you are working on a native version of Open Office, or is that asking too much?

yes, I am. Most patches have been already contributed to ASF OOo incubator project.
#8
Quote from: dryeo on 2012.02.05, 06:38:44
The OS/2 Mozilla port is built with GCC, currently 4.4.1 and as far as I can see that will continue to work for building Mozilla for the foresee-able future. We are at the limit of our tool chain though, most notably our linkers. We can barely link XUL.dll and can no longer build a debug version which makes things difficult.

IBM linkers all have different bugs, linking OpenOffice had been a problem with both 3.08 and ilinkv5; the watcom linker wlink is the only one able to correctly link every dll, even biggest ones (100MB with debug info).

And in gcc 4.4.6 I fixed a few problems related to linking a lot of files, mainly related to command line space exhaustion.
#9
Setup & Installation / Re: RPM packager
2011.08.31, 20:28:32
Hi all,

just a few notes about RPM/YUM development, just to report here something that I showed at WSE Europe in Harleem (NL), and something more.

While FHS tree is actually used, probably it can be reduced. I say 'probably' because this will require testing.

The choice to point UNIXROOT to a root directory of a drive has been done to simplify initial work; pointing UNIXROOT to a subdirectory could already work, but most apps are not tested in this environment.

Installation of packages to FHS is only forced for core packages: nothing precludes using different paths or even relocatable packages for other apps.

There is already a GUI, QYum (I know, not really fancy name...), which I made using QT4 with python bridge: it can already browse a repository and start an installation.

So, in the end, while the current behaviour of RPM/YUM mostly resembles an unix environment, nothing prevents us to get it more OS/2 friendly.

While release 00 is FHS structured, we can get release 01 to be more friendly, and it will update itself (at least I hope so, release 01 is still empty, so we can't test...). And then move to 02, 03, ...

We need only one thing: more resources (read developers) to work on it.

I hope you  will understand this work could give you a lot of features, please be patient.

thanks,

Yuri
#10
Applications / Re: RPM/YUM !
2011.01.03, 02:06:45
Quote from: melf on 2011.01.03, 00:23:48
I'm no programmer but have hard to figure out what suddenly has become so complicated in new programs, so we have to "borrow" an installer from unix? Incidently I'm not very fond of the unix way to do and write things, so an installer talking unix would be bad in my opinion.

rpm/yum already talks "os2" :-) it already handles config.sys, locked files, rexx scripts and WPS interface. It lacks a GUI now, but it will get one.
It installs software to UNIXROOT drive (or boot drive) by default, but if you are an advanced user you can make use of relocatable option and install where you want.

Yuri
#11
Applications / Re: RPM/YUM !
2011.01.03, 01:59:52
Quote from: CDRWSel on 2011.01.02, 17:45:00
1/ Why to use install tool which has more than 50MiB and requires billable internet connection ?

You can download .rpm files from http://rpm.netlabs.org and put them into a local directory, then setup a new repository on your HD adding

[bootstrap]
name = Local Bootstrap Repository
baseurl = file:///drives/f/temp/rpmbuild/RPMS
enabled=1

to /etc/yum/yum.conf.

The wiki will be updated soon.

Yuri
#12
Yes, I think it works for the 701 too, most of the info I gathered were for the 7xx  series.

#13
Programming / Re: SWT port image
2008.07.01, 18:59:24
Hi,

I'm busy on other things now, so I made available for download my test build of swt 3.3.4.9 with odin sdk:

http://web.os2power.com/download/swt-332.zip (6.5MB)

the zip includes swt.jar and full source code. To rebuild you need odin sdk tree and gcc 3.3.5.
This build is tested only against my personal Odin build tree, and surely it crashes when handling bmp images (here I have hacked gdi32 to not use memory mapping for reading files).

I'm not going to work on  it in the short time, but if someone wants to build it, I'll reply here.

Yuri
#14
Programming / Re: SWT port image
2008.05.30, 16:50:24
Quote from: saborion2 on 2008.05.30, 16:37:15

So, what if the adequate incentives schemes (Bounty Proposals, Development Resources, Maintenance Contracts et cetera et etcetera...) are offered (put in place) to attract the developers so that "projects" become more lucrative and the required "GA" Stages and Dates are quite easily achievable.


yes, they are a good system, but current offering is not enough to support a part time job, so current funds are good only for spare time development.

Yuri
#15
Programming / Re: SWT port image
2008.05.30, 15:13:51
Hi Leonardo,

Quote from: lpino on 2008.05.29, 23:04:32
Great to hear those news, but Im not a fan of ODIN ports. The more native the better. What JVM do you use for that port?, can you start Eclipse 3.x?

It cannot start programs like eclipse or azureus, but consider it took a couple of days to compile sources and create a native os2 dll. Jvm 1.5 or 1.4, it doesn't matter.

I understand Odin is not the preferred way, but it allows a really short development time. You can get sooner at latest level, and then you can inject support for native widgets in a second time.

Since only a few developers are active on OS/2, projects with less resource requirements are more interesting, and they are easier to put to GA level.

Yuri