Date: Mon, 24 Apr 2006 00:06:17 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 684 ************************************************** Sunday 23 April 2006 Number 684 ************************************************** Subjects for today 1 Re: Re: GCC and EMX : Kees de Lezenne Coulander 2 Re: Building tidy - now that I have a working LIBTOOL : Steven Levine" 3 Re: Building tidy - now that I have a working LIBTOOL : Steven Levine" 4 Re: Building tidy - now that I have a working LIBTOOL : Steven Levine" 5 Re: Building tidy - now that I have a working LIBTOOL : Dave Yeo" 6 Re: Building tidy - now that I have a working LIBTOOL : Dave Yeo" 7 Re: Building tidy - now that I have a working LIBTOOL : Dave Yeo" 8 Re: Building tidy - now that I have a working LIBTOOL : Steven Levine" 9 Re: Building tidy - now that I have a working LIBTOOL : Steven Levine" 10 Re: Building tidy - now that I have a working LIBTOOL : Steven Levine" 11 Re: LIBTOOL : Dave Yeo" 12 Re: Building tidy - now that I have a working LIBTOOL : Brendan Oakley" 13 Re: Building tidy - now that I have a working LIBTOOL : Dave Yeo" 14 Re: Building tidy - now that I have a working LIBTOOL : Dave Yeo" 15 Re: Building tidy - now that I have a working LIBTOOL : Dave Yeo" 16 Re: LIBTOOL : Stefan.Neis at t-online.de 17 Re: Building tidy - now that I have a working LIBTOOL : Christian Hennecke" **= Email 1 ==========================** Date: Sat, 22 Apr 2006 19:02:07 CET From: Kees de Lezenne Coulander Subject: Re: Re: GCC and EMX I posted this last night, but have not seen it appear on the list. My apologies if you receive it a second time. ** Reply to note from "Brendan Oakley" Fri, 21 Apr 2006 10:45:48 -0700 > > The Ada compiler has been ported, some time ago, by Robert Dewar: > > http://hobbes.nmsu.edu/cgi-bin/h-browse?sh=1&dir=//pub/os2/dev/emx/contrib/gnat > > The OS/2 API, including PM, is supported by ADA: > > http://hobbes.nmsu.edu/cgi-bin/h-browse?sh=1&dir=//pub/os2/dev/ada > > If I find a spot of time I just might try it out myself. > > Brendan You are talking about Professor Robert Dewar who lead the team that created gnat, the Ada compiler based on gcc. At the time (ca 1994), OS/2 was the only game in town to enable an Ada compiler to run on an IBM compatible PC. Robert Dewar himself ran OS/2 and did a large part of the compiler development on OS/2. A few years ago, however, he reluctantly switched to Windows, and the OS/2 version of gnat is no longer supported by AdaCore (http://www.adacore.com). Since then, the code for the Ada version of gcc has been merged into the official FSF gcc tree. The question is, how much of that is still applicable to OS/2. The gnat versions that we use at the moment are all still based on emx (gcc 2.8.1 or thereabouts). As far as I know, nobody has yet tried to build the Ada version of gcc 3.x.x or 4.x.x on OS/2. On other platforms, the experience with these new gcc versions and Ada has been rather mixed, as there have been extensive changes in the underlying gcc code with which the Ada front end has not quite caught up. This situation seems to be improving and the upcoming version of Debian is aiming for gcc 4.x.x with Ada. Kees de Lezenne Coulander **= Email 2 ==========================** Date: Sat, 22 Apr 2006 11:40:17 -0700 From: "Steven Levine" Subject: Re: Building tidy - now that I have a working LIBTOOL In , on 04/21/06 at 09:58 AM, "Brendan Oakley" said: Hi, >Yeah I think it's reasonable for our OS/2 patches to be applied. The more >we request that the more mainstream the OS/2 support will be. I'm a firm believer that what's most important is how you ask. The maintainers have little incentive to support OS/2, unless they happen to run OS/2. This is especially true if they perceive that others are asking them to do the work or that others seem to have a sense of entitlement. This is the way it works in open source. >Case in point, there is a fairly current OS/2 port of Sendmail, but the >Sendmail distro doesn't seem to be aware of it. The readme lists all >kinds of issues with obscure OS's I've never heard of, but nothing of >OS/2. A curious note in the docs is the brief "complaint" that developers >who port to their OS don't submit back the proper OS-specific files for >their port. If I was sufficiently interested in sendmail, I would be asking the porter this question, not the maintainer. It's not the maintainer's job to seek out the porters. The maintainer's have done their part by indicating they would be willing to accept patches. Regards, Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.67 #10183 Warp/eCS/DIY/14.103a_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 3 ==========================** Date: Sat, 22 Apr 2006 13:40:48 -0700 From: "Steven Levine" Subject: Re: Building tidy - now that I have a working LIBTOOL In <20060422022845.A34E2B8E51 at generation.lgisp.net>, on 04/21/06 at 07:28 PM, "Dave Yeo" said: >Pretty complicated patch , I spent most of my time using this as on opportunity to understand libtool better than I did. >I doubt it would be accepted. It's definitely ugly looking. >Simpler (and >maybe more likely to be excepted) is to >in include/platform.h >add && !defined(__INNOTEK_LIBC__) to the end of line 507 to stop warnings Yes. That's better. This would be even simplier if platform.h made use of HAVE_UINT and so on. However, it appears that gmake is the preferred build method. >make >and got >lt-tidy.exe 39249 04-21-06 7:16p >tab2space.exe 16540 04-21-06 7:05p >tidy.exe 39249 04-21-06 7:05p >tidy02R.dll 303191 04-21-06 7:05p This is what libtool does by default. If you --disable-shared, you will get a large tidy.exe without tidy02R.dll as in [j:/sla_dev2/tidy_dev/tidy/console]ll *.exe -rwxrwx--a 5672 Apr 22 13:40 tab2space.exe* -rwxrwx--a 241498 Apr 22 13:40 tidy.exe* >Tidy seems to work though I haven't tested too much. I just pulled the CVS sources so that I can run the tests. >ps no config.site etc either Are you saying you omitted LDFLAGS and LT_OS2_LDFLAGS and got an OMF executable? Regards, Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.67 #10183 Warp/eCS/DIY/14.103a_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 4 ==========================** Date: Sat, 22 Apr 2006 13:59:15 -0700 From: "Steven Levine" Subject: Re: Building tidy - now that I have a working LIBTOOL In <20060422041540.BB060B8F0B at generation.lgisp.net>, on 04/21/06 at 09:15 PM, "Dave Yeo" said: >Actually line 510 in include/platform.h should be >|| defined(__EMX__) Is this true for all EMX builds or just OS/2 EMX builds? >#ifdef __EMX__ > oldstdoutmode = setmode( fileno(stdout), O_BINARY ); > oldstderrmode = setmode( fileno(stderr), O_BINARY ); >#endif >though this may break VACPP builds. I don't think the currents sources will build on any OS/2 compiler, out of the box. Hartmut Krafft did an EMX build back in December and he needed these patches and more to tweak the gmake makefile. >tidy.exe which also seems to work (wish they had a test suite). They do. You'll need to pull it from CVS. >which I don't feel like tracking down right now. >Anyways with the above changes tidy.exe should build with any GCC from >2.95.3 up. Did you look at the gmake build or did you do everything with the gnuauto build? Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.67 #10183 Warp/eCS/DIY/14.103a_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 5 ==========================** Date: Sat, 22 Apr 2006 17:27:15 -0800 From: "Dave Yeo" Subject: Re: Building tidy - now that I have a working LIBTOOL On Sat, 22 Apr 2006 13:40:48 -0700, Steven Levine wrote: >I spent most of my time using this as on opportunity to understand libtool >better than I did. Have you any insights into this # Flag that allows shared libraries with undefined symbols to be built. allow_undefined_flag="unsupported" I've had to change this to "supported" in a few things to allow a DLL to be built. Testing seems to show the DLL to work but I really don't like changing something without knowing more. Dave **= Email 6 ==========================** Date: Sat, 22 Apr 2006 17:39:33 -0800 From: "Dave Yeo" Subject: Re: Building tidy - now that I have a working LIBTOOL On Sat, 22 Apr 2006 13:40:48 -0700, Steven Levine wrote: >Yes. That's better. This would be even simplier if platform.h made use of >HAVE_UINT and so on. However, it appears that gmake is the preferred >build method. Well I guess someone would have to submit a patch to use config.h, configure etc. >>ps no config.site etc either > >Are you saying you omitted LDFLAGS and LT_OS2_LDFLAGS and got an OMF >executable? Yes, I didn't set any flags at all. I presume it is an aout build as there is no -Zomf anywhere. GCC happily builds a DLL with -Zdll and aout object files and as far as I know always has. **= Email 7 ==========================** Date: Sat, 22 Apr 2006 18:02:48 -0800 From: "Dave Yeo" Subject: Re: Building tidy - now that I have a working LIBTOOL On Sat, 22 Apr 2006 13:59:15 -0700, Steven Levine wrote: >In <20060422041540.BB060B8F0B at generation.lgisp.net>, on 04/21/06 > at 09:15 PM, "Dave Yeo" said: > >>Actually line 510 in include/platform.h should be > >>|| defined(__EMX__) > >Is this true for all EMX builds or just OS/2 EMX builds? I'd guess all EMX builds. To build for anything besides OS/2 means using the stock 2.8.1 which basically uses the same headers as all the other EMX GCCs. I've tested with 3.0.3 and 3.2.1. They both need it. In a way now EMX is the symbol usually used in *nix ports to signify OS/2 > >>#ifdef __EMX__ >> oldstdoutmode = setmode( fileno(stdout), O_BINARY ); >> oldstderrmode = setmode( fileno(stderr), O_BINARY ); >>#endif > >>though this may break VACPP builds. > >I don't think the currents sources will build on any OS/2 compiler, out of >the box. Hartmut Krafft did an EMX build back in December and he needed >these patches and more to tweak the gmake makefile. > >>tidy.exe which also seems to work (wish they had a test suite). > >They do. You'll need to pull it from CVS. I'll try that later > >>which I don't feel like tracking down right now. >>Anyways with the above changes tidy.exe should build with any GCC from >>2.95.3 up. > >Did you look at the gmake build or did you do everything with the gnuauto >build? > I haven't looked at the gmake file (have now, doesn't get far here). I usually have good luck with the auto tools so I just used them. Lately I usually rebuild everything with aclocal -I /usr/share/aclocal libtoolize -c --force autoheader automake --foreign -a -c autoconf configure --help etc Dave **= Email 8 ==========================** Date: Sat, 22 Apr 2006 18:35:59 -0700 From: "Steven Levine" Subject: Re: Building tidy - now that I have a working LIBTOOL In <20060423002716.D0433B8C6C at generation.lgisp.net>, on 04/22/06 at 05:27 PM, "Dave Yeo" said: Hi, >Have you any insights into this ># Flag that allows shared libraries with undefined symbols to be built. >allow_undefined_flag="unsupported" Some, now that I looked at the libtool code. By default, all symbols in shared libraries must be fully resolved at link time. When set to supported, libtool arranges to pass the linker specific argement that overrides this requirement. I'm not sure how this applies to building OS/2 DLLs. Perhaps it's a libtool version issue. v1.5 is the first libtool version that worked for me on OS/2 and, best I can tell, it has a lot of Knut specific code, when I compare it to the v1.5.22 sources. >I've had to change this to "supported" in a few things to allow a DLL to >be built. Testing seems to show the DLL to work but I really don't like >changing something without knowing more. I'd have to see the actual failure before I can say why this occurred and how it applies to OS2 DLLs. It may be related to call by name compared to call by ordinal. It may also be related to libtool's limitations in resolving library dependencies. If you haven't done so already scan libtool for allow_undefined_flag and allow_undefined to see what the option is doing. Another thing I find helpful with scripted tools like libtool is to grab the command line from the log and run something like sh -x libtool --verbose blah blah blah... BTW, I'm now building tidy from the current cvs sources HTML Tidy for OS/2 released on 14 February 2006 Built by Steven H. Levine on Apr 22 2006 16:34:32 although I have not run the tests yet. We will see what Terry Teague has to say about accepting patches. Regards, Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.67 #10183 Warp/eCS/DIY/14.103a_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 9 ==========================** Date: Sat, 22 Apr 2006 19:26:00 -0700 From: "Steven Levine" Subject: Re: Building tidy - now that I have a working LIBTOOL In <20060423012616.58F68B8F4E at generation.lgisp.net>, on 04/22/06 at 05:39 PM, "Dave Yeo" said: >Well I guess someone would have to submit a patch to use config.h, >configure etc. It was only wishful thinking on my part. The maintainers prefer gmake for the official builds, so this is unlikely to be accepted. >Yes, I didn't set any flags at all. I presume it is an aout build as >there is no -Zomf anywhere. GCC happily builds a DLL with -Zdll and aout >object files and as far as I know always has. I tried this after you mentioned it. Perhaps I missed a change in the defaults. The gcc toolchain is not my strong point. I thought -Zomf was preferred. Perhaps it does not matter all that much with gcc 3.x, since the "emxbind" is sorta automatic. Regards, Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.67 #10183 Warp/eCS/DIY/14.103a_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 10 ==========================** Date: Sat, 22 Apr 2006 19:52:32 -0700 From: "Steven Levine" Subject: Re: Building tidy - now that I have a working LIBTOOL In <20060423012635.C32CEB8C75 at generation.lgisp.net>, on 04/22/06 at 06:02 PM, "Dave Yeo" said: >I haven't looked at the gmake file (have now, doesn't get far here). True. It needs help. You can look at the diffs in Harmutt's tidy-os2-bin-20051026-1.zip on Hobbes. >I usually have good luck with the auto tools so I just used them. I prefer them because I believe they are the best long term solution to keep apps current on OS/2. Also, while it may not be perfect, it's a standard. >aclocal -I /usr/share/aclocal >libtoolize -c --force >autoheader >automake --foreign -a -c >autoconf >configure --help That looks suspiciously close to tidy's build.sh. :-) Regards, Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.67 #10183 Warp/eCS/DIY/14.103a_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 11 ==========================** Date: Sat, 22 Apr 2006 20:33:39 -0800 From: "Dave Yeo" Subject: Re: LIBTOOL On Sat, 22 Apr 2006 18:35:59 -0700, Steven Levine wrote: >In <20060423002716.D0433B8C6C at generation.lgisp.net>, on 04/22/06 > at 05:27 PM, "Dave Yeo" said: > >Hi, > >>Have you any insights into this >># Flag that allows shared libraries with undefined symbols to be built. >>allow_undefined_flag="unsupported" > >Some, now that I looked at the libtool code. By default, all symbols in >shared libraries must be fully resolved at link time. When set to >supported, libtool arranges to pass the linker specific argement that >overrides this requirement. > >I'm not sure how this applies to building OS/2 DLLs. Perhaps it's a >libtool version issue. v1.5 is the first libtool version that worked for >me on OS/2 and, best I can tell, it has a lot of Knut specific code, when >I compare it to the v1.5.22 sources. Andreas ports worked for me (building either a shared or a static) as well and have the same limitation. One thing would be nice, to use your own DEF file > >>I've had to change this to "supported" in a few things to allow a DLL to >>be built. Testing seems to show the DLL to work but I really don't like >>changing something without knowing more. > >I'd have to see the actual failure before I can say why this occurred and >how it applies to OS2 DLLs. It may be related to call by name compared to >call by ordinal. It may also be related to libtool's limitations in >resolving library dependencies. f:/usr/bin/sh.exe ../libtool --tag=CC --mode=link gcc -g -O2 -o libfontconfig.la -rpath /usr/local/lib -version-info 1:4:0 fcatomic.lo fcblanks.lo fccache.lo fccfg.lo fccharset.lo fcdbg.lo fcdefault.lo fcdir.lo fcfreetype.lo fcfs.lo fcinit.lo fclang.lo fclist.lo fcmatch.lo fcmatrix.lo fcname.lo fcpat.lo fcstr.lo fcxml.lo -L/usr/local/lib -lfreetype -lz -lexpat libtool: link: warning: undefined symbols not allowed in i386-pc-os2-emx shared libraries is a basic failure. In this case Doodles port of fontconfig which uses Presentation Manager features though I see this failure with lots of other ones too. > >If you haven't done so already scan libtool for allow_undefined_flag and >allow_undefined to see what the option is doing. > >Another thing I find helpful with scripted tools like libtool is to grab >the command line from the log and run something like > > sh -x libtool --verbose blah blah blah... actually libtool --debug and I can't see why it fails (lots of output) > >BTW, I'm now building tidy from the current cvs sources > > HTML Tidy for OS/2 released on 14 February 2006 > Built by Steven H. Levine on Apr 22 2006 16:34:32 > >although I have not run the tests yet. the tests all passed on my builds > >We will see what Terry Teague has to say about accepting patches. > Dave **= Email 12 ==========================** Date: Sat, 22 Apr 2006 21:02:51 -0700 From: "Brendan Oakley" Subject: Re: Building tidy - now that I have a working LIBTOOL ------=_Part_1420_23070133.1145764971409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 4/22/06, Steven Levine wrote: > > In , on > 04/21/06 > at 09:58 AM, "Brendan Oakley" said: > > Hi, > > >Yeah I think it's reasonable for our OS/2 patches to be applied. The mor= e > >we request that the more mainstream the OS/2 support will be. > > I'm a firm believer that what's most important is how you ask. The > maintainers have little incentive to support OS/2, unless they happen to > run OS/2. This is especially true if they perceive that others are askin= g > them to do the work or that others seem to have a sense of entitlement. > This is the way it works in open source. > > >Case in point, there is a fairly current OS/2 port of Sendmail, but the > >Sendmail distro doesn't seem to be aware of it. The readme lists all > >kinds of issues with obscure OS's I've never heard of, but nothing of > >OS/2. A curious note in the docs is the brief "complaint" that developer= s > >who port to their OS don't submit back the proper OS-specific files for > >their port. > > If I was sufficiently interested in sendmail, I would be asking the porte= r > this question, not the maintainer. It's not the maintainer's job to seek > out the porters. The maintainer's have done their part by indicating the= y > would be willing to accept patches. > > Regards, > > Steven > > -- > ---------------------------------------------------------------------- > "Steven Levine" MR2/ICE 2.67 #10183 > Warp/eCS/DIY/14.103a_W4 > www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) > ---------------------------------------------------------------------- > > > Hi Steven. You're right. I think that is pretty much what I meant. In the case of Sendmail, there are mechanisms in place for handling differences across platforms, and the developers seem at least to be willing to accept patches= , but like with anything, within reason and without expecting them to do ongoing work. I looked briefly at the older Sendmail port last night, and it does not see= m at first glance to conform to the way the Sendmail developers expect them t= o be done, so it is not surprising that it was either not submitted or not accepted. Still useful, though, to see what needs doing. Brendan ------=_Part_1420_23070133.1145764971409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
On 4/22/06, = Steven Levine <steve53 at eart= hlink.net> wrote:
In <d2b4f47c0604210958pc8f5= 82qd17758f4e36bc9ec at mail.gmail.com >, on
04/21/06
  at 09:58 AM, "Brendan Oakley&q= uot; <gentux2 at gmail.com> sai= d:

Hi,

>Yeah I think it's reasonable for our OS/2 patches = to be applied. The more
>we request that the more mainstream the OS/2 support will be.
I'm a firm believer that what's most important is how you ask.  = ;The
maintainers have little incentive to support OS/2, unless they happ= en to
run OS/2.  This is especially true if they perceive that others a= re asking
them to do the work or that others seem to have a sense of ent= itlement.
This is the way it works in open source.

>Case in po= int, there is a fairly current OS/2 port of Sendmail, but the
>Sendmail distro doesn't seem to be aware of it. The readme lists al= l
>kinds of issues with obscure OS's I've never heard of, but nothing= of
>OS/2. A curious note in the docs is the brief "complaint&qu= ot; that developers
>who port to their OS don't submit back the proper OS-specific files= for
>their port.

If I was sufficiently interested in sendmail= , I would be asking the porter
this question, not the maintainer. &= nbsp;It's not the maintainer's job to seek
out the porters.  The maintainer's have done their part by in= dicating they
would be willing to accept patches.

Regards,
Steven

--
------------------------------------------------------= ----------------
"Steven Levine" <= steve53 at earthlink.net>  MR2/ICE 2.67 #10183 Warp/eCS/DIY/1= 4.103a_W4
www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
----------------------------= ------------------------------------------



Hi Steven.
 
You're right. I think that is pretty much what I meant. In the case of= Sendmail, there are mechanisms in place for handling differences across pl= atforms, and the developers seem at least to be willing to a= ccept patches, but like with anything, within reason and without expecting = them to do ongoing work.
 
I looked briefly at the older Sendmail port last night, and it does no= t seem at first glance to conform to the way the Sendmail developers expect= them to be done, so it is not surprising that it was either not submi= tted or not accepted. Still useful, though, to see what needs doing.
 
Brendan
------=_Part_1420_23070133.1145764971409-- **= Email 13 ==========================** Date: Sat, 22 Apr 2006 21:23:16 -0800 From: "Dave Yeo" Subject: Re: Building tidy - now that I have a working LIBTOOL On Sat, 22 Apr 2006 19:52:32 -0700, Steven Levine wrote: >>aclocal -I /usr/share/aclocal >>libtoolize -c --force >>autoheader >>automake --foreign -a -c >>autoconf >>configure --help > >That looks suspiciously close to tidy's build.sh. :-) And quite a few autogen.sh's. Though some do version testing as well. I stole the above from blackbox Sometimes also aclocal needs more -I somepath passed to it eg -I . Dave **= Email 14 ==========================** Date: Sat, 22 Apr 2006 21:20:04 -0800 From: "Dave Yeo" Subject: Re: Building tidy - now that I have a working LIBTOOL On Sat, 22 Apr 2006 19:26:00 -0700, Steven Levine wrote: > >I tried this after you mentioned it. Perhaps I missed a change in the >defaults. The gcc toolchain is not my strong point. I thought -Zomf was >preferred. Perhaps it does not matter all that much with gcc 3.x, since >the "emxbind" is sorta automatic. Just tested (I have a zlib makefile which doesn't use -Zomf) and even GCC 2.8.1 can produce a DLL without -Zomf Dave **= Email 15 ==========================** Date: Sat, 22 Apr 2006 21:43:55 -0800 From: "Dave Yeo" Subject: Re: Building tidy - now that I have a working LIBTOOL On Sat, 22 Apr 2006 19:52:32 -0700, Steven Levine wrote: >True. It needs help. You can look at the diffs in Harmutt's >tidy-os2-bin-20051026-1.zip on Hobbes. Interesting. Where I recommended __EMX__ I guess should be OS2_OS Dave **= Email 16 ==========================** Date: Sun, 23 Apr 2006 11:13:37 +0100 From: Stefan.Neis at t-online.de Subject: Re: LIBTOOL Hi, > f:/usr/bin/sh.exe ../libtool --tag=CC --mode=link gcc -g -O2 -o libfontconfig.la -rpath /usr/local/lib -version-info 1:4:0 fcatomic.lo fcblanks.lo fccache.lo fccfg.lo fccharset.lo fcdbg.lo fcdefault.lo fcdir.lo fcfreetype.lo fcfs.lo fcinit.lo fclang.lo fclist.lo fcmatch.lo fcmatrix.lo fcname.lo fcpat.lo fcstr.lo fcxml.lo -L/usr/local/lib -lfreetype -lz -lexpat > libtool: link: warning: undefined symbols not allowed in i386-pc-os2-emx shared libraries I think (though I didn't check) the point of this is that shared libraries on ELF platforms may reference symbols that are defined in the executable itself, which AFAIK does not work for DLLs (neither on OS/2 nor on Windoze) **= Email 17 ==========================** Date: Sun, 23 Apr 2006 13:59:55 +0200 (CEST) From: "Christian Hennecke" Subject: Re: Building tidy - now that I have a working LIBTOOL On Sat, 22 Apr 2006 11:40:17 -0700, Steven Levine wrote: >>Yeah I think it's reasonable for our OS/2 patches to be applied. The more >>we request that the more mainstream the OS/2 support will be. > >I'm a firm believer that what's most important is how you ask. The >maintainers have little incentive to support OS/2, unless they happen to >run OS/2. This is especially true if they perceive that others are asking >them to do the work or that others seem to have a sense of entitlement. >This is the way it works in open source. Well, I did ask quite politely. After a few mails they said that they would accept my code for the IBM858 codepage if I also added support for Latin-9. That was quite easy, so I agreed. Christian Hennecke