GLIB modern version?
Marty
OS/2? I only see a 1.2.x version on Hobbes. Might be good enough for
Mozilla, but I need something newer (with glib-object.h and gmodule.h).
--
Reverse the parts of the e-mail address to reply by mail.
Dave Yeo
> Has someone succeeded in porting a reasonably recent version of GLIB to
> OS/2? I only see a 1.2.x version on Hobbes. Might be good enough for
> Mozilla, but I need something newer (with glib-object.h and gmodule.h).
>
Paul has the newest I'm aware off. Unluckily the newer glibs keep adding
stuff that is non-trivial to port like virtual file systems
Dave
Marty
Sorry I've been out of the loop for a while, so I'm not sure where to
find this. Do you have a link handy so I can check it out? I'd like to
port libpurple, which is the protocol-only (in theory at least) portion
of the Pidgin instant messenger program. I figure I can build a native
GUI on top of that to make something with reliable connectivity for OS/2.
Dave Yeo
There is a diff here, http://smedley.info/glib-2.18.4.diff.
Is there any decent QT instant messaging programs? The port of QT4 at
netlabs is coming along nicely
Dave
Marty
Thanks! So I'm guessing I just apply this diff to the 2.18.4 release
and I should have an OS/2 port. Sounds great, thanks for the link.
Couldn't find this on Paul's proper pages, unfortunately, but I'm glad
you had a direct pointer.
Not sure if there are any QT IMs. But Pidgin is the best that I've come
across and it supports tons of protocols all at once.
Dave Yeo
>> > There is a diff here,http://smedley.info/glib-2.18.4.diff.
>> > Is there any decent QT instant messaging programs? The port of QT4 at
>> > netlabs is coming along nicely
>> > Dave
> Thanks! So I'm guessing I just apply this diff to the 2.18.4 release
> and I should have an OS/2 port. Sounds great, thanks for the link.
> Couldn't find this on Paul's proper pages, unfortunately, but I'm glad
> you had a direct pointer.
>
I actually applied it to a slightly different version, it needed a bit
of work to apply and worked fine for what I needed. As I mentioned, more
and more functionality has been added to glib and some of them are not
enabled like the virtual file stuff.
I'd guess that it has all the functionality that pidgin needs, best to
look at the oldest version that pidgin depends on.
Dave
Marty
I've got it all compiling, but linking is a complete mess. Possibly
because of the way configure created libtool to work, but I'm not sure.
I've been too far removed from this stuff for too long. Basically,
it's building up everything in aout format (*.o, *.a), but when it uses
the GCC frontend to link some of the symbols defined in the .a library
are not being found. More perplexing is that it's saying that the
undefined symbol reference was within the library itself too! For
example, if a library contains modules A and B, and module A defines
function f1, and B defines f2, the error is like this:
A.c:<linenum> (<library_name>.a(A.o)): Undefined symbol f2 referenced
from text segment
They're in the same library (I can see them, with the same name using
nm), all there, but it is not resolving within itself.
The command line issued by libtool looks like this:
gcc -g -O2 -Wall -o gtester.exe gtester.o ./.libs/glib-2.0.a
I tried also using the -L and -l parameters to point to the library and
it made no difference. I also tried moving the library in front of the
gtester.o file and it created even more errors. Basically it looks like
there is some order dependence that is fastened into the library itself
and the symbols are coming out in the wrong order.
What can I do about this, short of detangling the web of dependencies
myself and writing my own makefile?
--
[Reverse the parts of the e-mail address to reply.]
Ilya Zakharevich
> I've got it all compiling, but linking is a complete mess. Possibly
> because of the way configure created libtool to work, but I'm not sure.
> I've been too far removed from this stuff for too long. Basically,
> it's building up everything in aout format (*.o, *.a), but when it uses
> the GCC frontend to link some of the symbols defined in the .a library
> are not being found. More perplexing is that it's saying that the
> undefined symbol reference was within the library itself too! For
> example, if a library contains modules A and B, and module A defines
> function f1, and B defines f2, the error is like this:
>
> A.c:<linenum> (<library_name>.a(A.o)): Undefined symbol f2 referenced
> from text segment
>
> They're in the same library (I can see them, with the same name using
> nm), all there, but it is not resolving within itself.
Maybe your `nm' has a different underscore convention?
Yours,
Ilya
Dave Yeo
[...]
>
> I've got it all compiling, but linking is a complete mess. Possibly
> because of the way configure created libtool to work, but I'm not sure.
> I've been too far removed from this stuff for too long. Basically, it's
> building up everything in aout format (*.o, *.a), but when it uses the
> GCC frontend to link some of the symbols defined in the .a library are
> not being found. More perplexing is that it's saying that the undefined
> symbol reference was within the library itself too! For example, if a
> library contains modules A and B, and module A defines function f1, and
> B defines f2, the error is like this:
>
> A.c:<linenum> (<library_name>.a(A.o)): Undefined symbol f2 referenced
> from text segment
>
> They're in the same library (I can see them, with the same name using
> nm), all there, but it is not resolving within itself.
>
> The command line issued by libtool looks like this:
> gcc -g -O2 -Wall -o gtester.exe gtester.o ./.libs/glib-2.0.a
That is weird. I just tried building here and gtester.exe links fine
with the same command line. Linking does fall apart when building the
tests due to bugs in libtool. Also trying to build a DLL (make
LDFLAGS=-no-undefined) fails with
gunicollate.c:216 (.libs/gunicollate.o): Undefined symbol _wcsxfrm
referenced from text segment
gunicollate.c:218 (.libs/gunicollate.o): Undefined symbol _wcsxfrm
referenced from text segment
I built with configure --with-threads=pthread --without-x
using Yuri's pthread library.
>
> I tried also using the -L and -l parameters to point to the library and
> it made no difference. I also tried moving the library in front of the
> gtester.o file and it created even more errors. Basically it looks like
> there is some order dependence that is fastened into the library itself
> and the symbols are coming out in the wrong order.
>
> What can I do about this, short of detangling the web of dependencies
> myself and writing my own makefile?
>
You could try updating libtool to a more OS/2 friendly version.
http://hobbes.nmsu.edu/download/pub/os2/dev/util/libtool-1.5.26.zip
probably also need
http://hobbes.nmsu.edu/download/pub/os2/dev/util/automake-1.10.1.zip for
aclocal and autoconf 2.61 is in the same directory.
run like so
sh libtoolize --force -copy
sh aclocal -I .
Dave
Marty
I think nm just tells it like it is, right? No translation, just dump
the symbol names. It came from the same package as GCC 3.3.5. I'm
using GCC 4.4.2 for the build, which on OS/2 is a bolt-on, on top of
3.3.5 as far as I'm aware.
Marty
I "guided" (hacked) configure to figure out the right answers, except
I'm not using the threaded library. Libpurple itself only operates in a
single thread (warns, in fact, that it is not at all thread safe), so I
figure that I don't need a threaded implementation of GLIB.
>> I tried also using the -L and -l parameters to point to the library and
>> it made no difference. I also tried moving the library in front of the
>> gtester.o file and it created even more errors. Basically it looks like
>> there is some order dependence that is fastened into the library itself
>> and the symbols are coming out in the wrong order.
>>
>> What can I do about this, short of detangling the web of dependencies
>> myself and writing my own makefile?
>
> You could try updating libtool to a more OS/2 friendly version.
> http://hobbes.nmsu.edu/download/pub/os2/dev/util/libtool-1.5.26.zip
This was the first thing I tried when I gave up on theirs.
Unfortunately, it yielded the same results.
> probably also need
> http://hobbes.nmsu.edu/download/pub/os2/dev/util/automake-1.10.1.zip for
> aclocal and autoconf 2.61 is in the same directory.
> run like so
> sh libtoolize --force -copy
> sh aclocal -I .
Did not install the automake stuff (must not need it), but this is worth
a shot. If I can't get this going, then I may just ask you to send me
your precompiled GLIB (since building GLIB is just a means to an end for
me). Then I can roll my own build scripts and environment for libpurple
if it gives me trouble. I'll report back if this gets me going, thanks.
Dave Yeo
I had a lot of problems trying to build an earlier version of glib2
without threading. I finally decided that the no threading option was
broken and reverted to using pthreads which did work.
As far as I know it is up to the individual programs using glib whether
they want to use threads so libpurple shouldn't care if glib is built
with threads. Note that most releases of glib are built with threads.
>
>>> I tried also using the -L and -l parameters to point to the library and
>>> it made no difference. I also tried moving the library in front of the
>>> gtester.o file and it created even more errors. Basically it looks like
>>> there is some order dependence that is fastened into the library itself
>>> and the symbols are coming out in the wrong order.
>>>
>>> What can I do about this, short of detangling the web of dependencies
>>> myself and writing my own makefile?
>>
>> You could try updating libtool to a more OS/2 friendly version.
>> http://hobbes.nmsu.edu/download/pub/os2/dev/util/libtool-1.5.26.zip
>
> This was the first thing I tried when I gave up on theirs.
> Unfortunately, it yielded the same results.
>
>> probably also need
>> http://hobbes.nmsu.edu/download/pub/os2/dev/util/automake-1.10.1.zip
>> for aclocal and autoconf 2.61 is in the same directory.
>> run like so
>> sh libtoolize --force -copy
>> sh aclocal -I .
>
> Did not install the automake stuff (must not need it), but this is worth
> a shot. If I can't get this going, then I may just ask you to send me
> your precompiled GLIB (since building GLIB is just a means to an end for
> me). Then I can roll my own build scripts and environment for libpurple
> if it gives me trouble. I'll report back if this gets me going, thanks.
>
The automake is just to get aclocal which might only be needed if you're
planning on running autoconf.
There is also a port of glib2 here,
ftp://ftp.netlabs.org/pub/libc/contrib/libs/glib-2.12.-rc1-multithreaded.zip
if an older one will work. Otherwise let me know if you need mine and
I'll send it
Dave
Ilya Zakharevich
>>> A.c:<linenum> (<library_name>.a(A.o)): Undefined symbol f2 referenced
>>> from text segment
>>>
>>> They're in the same library (I can see them, with the same name using
>>> nm), all there, but it is not resolving within itself.
>>
>> Maybe your `nm' has a different underscore convention?
> I think nm just tells it like it is, right? No translation, just dump
> the symbol names.
May Depend. E.g., my emxomfnm would fake a leading underscore (which
were automatically removed by EMX' aout-->omf conversion).
Yours,
Ilya
Dave Yeo
I've seen projects that use nm to check if a platform needs a leading
underscore.
Dave
Ilya Zakharevich
> On 12/29/09 07:40 pm, Ilya Zakharevich wrote:
>> On 2009-12-29, Marty<n...@comcast.martyamodeo> wrote:
>>>>> A.c:<linenum> (<library_name>.a(A.o)): Undefined symbol f2 referenced
>>>>> from text segment
>>>>>
>>>>> They're in the same library (I can see them, with the same name using
>>>>> nm), all there, but it is not resolving within itself.
>>>>
>>>> Maybe your `nm' has a different underscore convention?
>>
>>> I think nm just tells it like it is, right? No translation, just dump
>>> the symbol names.
>>
>> May Depend. E.g., my emxomfnm would fake a leading underscore (which
>> were automatically removed by EMX' aout-->omf conversion).
> I've seen projects that use nm to check if a platform needs a leading
> underscore.
This was exactly the first context I needed emxomfnm for. nm should
match what `as' or `gcc -S' is doing, otherwise problems would arise
in matching assembler to C. In particular, I needed to add
underscores to the names in .obj file tables.
Yours,
Ilya
J de Boyne Pollard
referenced from text segment
Long experience has me muttering "ranlib" at this point. So have a
hint: "ranlib!"
Marty
"An archive with such an index [created by ranlib] speeds up linking
to the library and allows routines in the library to call each other
without regard to their placement in the archive."
Sounds spot-on! Configure wound up defining RANLIB as "echo". I
changed it but sadly, it didn't seem to make one bit of difference. Is
this function dummied out on OS/2? This is the one I'm using:
6-12-07 1:48a 40,960 124 ranlib.exe
GNU ranlib 2.14 20030612
Dave Yeo
You probably have a set RANLIB=echo somewhere as ranlib doesn't work
with OMF libraries. Whether it is needed depends on the flags that are
passed to ar.
IIRC you mentioned using GCC 4.4.1, you should also update your binutils
http://os2ports.smedley.info/index.php?page=gnu-binutils
Best to put them in your GCC 4.4.1 directory and still have the default
3.3.5 in case you need to do some debugging or just compare compilers.
Dave
Marty
> On 12/30/09 11:47 am, Marty wrote:
>> J de Boyne Pollard wrote:
>>> M> A.c:<linenum> (<library_name>.a(A.o)): Undefined symbol f2
>>> referenced from text segment
>>>
>>> Long experience has me muttering "ranlib" at this point. So have a
>>> hint: "ranlib!"
>>
>> "An archive with such an index [created by ranlib] speeds up linking to
>> the library and allows routines in the library to call each other
>> without regard to their placement in the archive."
>>
>> Sounds spot-on! Configure wound up defining RANLIB as "echo". I changed
>> it but sadly, it didn't seem to make one bit of difference. Is this
>> function dummied out on OS/2? This is the one I'm using:
>>
>> 6-12-07 1:48a 40,960 124 ranlib.exe
>>
>> GNU ranlib 2.14 20030612
>
> You probably have a set RANLIB=echo somewhere as ranlib doesn't work
> with OMF libraries. Whether it is needed depends on the flags that are
> passed to ar.
I'm not building OMF libraries. It's building *.a archives. The ar
command is "ar cru lib.a object.o ...".
> IIRC you mentioned using GCC 4.4.1, you should also update your binutils
> http://os2ports.smedley.info/index.php?page=gnu-binutils
I think I did, but I'll double-check.
> Best to put them in your GCC 4.4.1 directory and still have the default
> 3.3.5 in case you need to do some debugging or just compare compilers.
> Dave
Yup. I did this.
Marty
> The automake is just to get aclocal which might only be needed if you're
> planning on running autoconf.
> There is also a port of glib2 here,
> ftp://ftp.netlabs.org/pub/libc/contrib/libs/glib-2.12.-rc1-multithreaded.zip
> if an older one will work. Otherwise let me know if you need mine and
> I'll send it
This build seems to get most of libpurple compiling. Haven't tried to
link anything yet because I'm still tweaking my config.h to get the rest
of everything building. But this definitely moves me quite a bit
forward, so thanks. I still am curious why I had the problem building
GLIB though, so I'll keep looking into it on the side.
Dave Yeo
>>> GNU ranlib 2.14 20030612
>>
>> You probably have a set RANLIB=echo somewhere as ranlib doesn't work
>> with OMF libraries. Whether it is needed depends on the flags that are
>> passed to ar.
>
> I'm not building OMF libraries. It's building *.a archives. The ar
> command is "ar cru lib.a object.o ...".
Configure should of found ranlib unless it is overridden in the
environment with eg set RANLIB=echo. Usually this is done for OMF, so
maybe you did this in the past and forgot.
The s parametre tells ar to do the ranlib thing so you do need ranlib
with the above command.
>
>> IIRC you mentioned using GCC 4.4.1, you should also update your
>> binutils http://os2ports.smedley.info/index.php?page=gnu-binutils
>
> I think I did, but I'll double-check.
The one I'm using with GCC 4.4.2 is
GNU ar (GNU Binutils) 2.19.1
so that may be your problem
Dave
Marty
> On 12/31/09 12:37 pm, Marty wrote:
>>>> GNU ranlib 2.14 20030612
>>>
>>> You probably have a set RANLIB=echo somewhere as ranlib doesn't work
>>> with OMF libraries. Whether it is needed depends on the flags that are
>>> passed to ar.
>>
>> I'm not building OMF libraries. It's building *.a archives. The ar
>> command is "ar cru lib.a object.o ...".
>
> Configure should of found ranlib unless it is overridden in the
> environment with eg set RANLIB=echo. Usually this is done for OMF, so
> maybe you did this in the past and forgot.
> The s parametre tells ar to do the ranlib thing so you do need ranlib
> with the above command.
There were some issues parsing through the paths in configure. My
native PATH environment variable had \B in it (like .....\bin, etc.) So
these were eaten as backspaces before they were passed on the sed to
translate "\"s to "/"s. Found it simpler just to override configure for
these cases.
>>> IIRC you mentioned using GCC 4.4.1, you should also update your
>>> binutils http://os2ports.smedley.info/index.php?page=gnu-binutils
>>
>> I think I did, but I'll double-check.
>
> The one I'm using with GCC 4.4.2 is
> GNU ar (GNU Binutils) 2.19.1
> so that may be your problem
I was at 2.14, so I updated. Still the same behavior though. :-(
One more side question. The libpurple build is looking for a definition
for socklen_t. I find a definition for __socklen_t in sys\_types.h
(included by sys\types.h). Clearly, it should be a 32-bit int, which I
can just force in there, but in which include file is the
non-underscored version supposed to be defined? In spite of my best
efforts, it's looking like my development environment is too much "ad
hoc" and not enough "out-of-the-box installation".
Dave Yeo
[...]
>
> One more side question. The libpurple build is looking for a definition
> for socklen_t. I find a definition for __socklen_t in sys\_types.h
> (included by sys\types.h). Clearly, it should be a 32-bit int, which I
> can just force in there, but in which include file is the
> non-underscored version supposed to be defined? In spite of my best
> efforts, it's looking like my development environment is too much "ad
> hoc" and not enough "out-of-the-box installation".
We're missing socklen_t, it should be declared in sys/types.h or
preferably sys/socket.h,
http://opengroup.org/onlinepubs/007908799/xns/syssocket.h.html
Just typedef it as an int
Dave
Rich Walsh
> One more side question. The libpurple build is looking for a definition
> for socklen_t. I find a definition for __socklen_t in sys\_types.h
> (included by sys\types.h). Clearly, it should be a 32-bit int, which I
> can just force in there, but in which include file is the
> non-underscored version supposed to be defined?
The opengroup.org SUS says it _should_ be in sys/socket.h but it
isn't there (or anywhere else) in our 3.3.5/4.x.x headers. See:
http://opengroup.org/onlinepubs/007908799/xns/syssocket.h.html
--
== == almost usable email address: Rich AT E-vertise.Com == ==
___________________________________________________________________
|
| DragText v3.9 with NLS support
Rich Walsh | A Distinctly Different Desktop Enhancement
Ft Myers, FL | http://e-vertise.com/dragtext/
___________________________________________________________________
Marty
Thanks (and to Rich too). Looks like it should be unsigned int.
I've got the base interface of libpurple compiling now. On to the
protocols...
--
Reverse the parts of the e-mail address to reply by mail.