Re: [Context] [Dev-luatex] Luatex 0.43.0 announcement
On Wed, Aug 19, 2009 at 10:53, Taco Hoekwater wrote:
I have just uploaded the archives for a new luatex release, 0.43.0.
Taco, thanks a lot. But the build on debian sarge (the one where I compile binaries for minimals) fails. It's something like: web2c/luatexdir/image/pdftoepdf.cc:1052: error: invalid conversion from 'void (*)(...)' to 'void (*)(void*, void*)' and some more errors before, ... but I need to figure out how to copy-paste text and most of all how to scroll a few lines back in terminal, or figure out where the log file is :) (I'm using VMWare Fusion and have not much experience with it.) Mojca
Mojca Miklavec wrote:
On Wed, Aug 19, 2009 at 10:53, Taco Hoekwater wrote:
I have just uploaded the archives for a new luatex release, 0.43.0.
Taco, thanks a lot. But the build on debian sarge (the one where I compile binaries for minimals) fails.
It's something like:
web2c/luatexdir/image/pdftoepdf.cc:1052: error: invalid conversion from 'void (*)(...)' to 'void (*)(void*, void*)' and some more errors before,
... but I need to figure out how to copy-paste text and most of all how to scroll a few lines back in terminal, or figure out where the log file is :)
When you do, don't forget to report the gcc version as well. Best wishes, Taco
Mojca Miklavec wrote:
On Wed, Aug 19, 2009 at 10:53, Taco Hoekwater wrote:
I have just uploaded the archives for a new luatex release, 0.43.0.
Taco, thanks a lot. But the build on debian sarge (the one where I compile binaries for minimals) fails.
It's something like:
web2c/luatexdir/image/pdftoepdf.cc:1052: error: invalid conversion from 'void (*)(...)' to 'void (*)(void*, void*)' and some more errors before,
Looking at the source, it seems this could happen if it fails to load utils/avl.h and/or utils/avlstuff.h. I don't see how that could happen, though. Best wishes, Taco
Taco Hoekwater wrote:
Mojca Miklavec wrote:
On Wed, Aug 19, 2009 at 10:53, Taco Hoekwater wrote:
I have just uploaded the archives for a new luatex release, 0.43.0.
Taco, thanks a lot. But the build on debian sarge (the one where I compile binaries for minimals) fails.
It's something like:
web2c/luatexdir/image/pdftoepdf.cc:1052: error: invalid conversion from 'void (*)(...)' to 'void (*)(void*, void*)' and some more errors before,
Looking at the source, it seems this could happen if it fails to load utils/avl.h and/or utils/avlstuff.h. I don't see how that could happen, though.
I just ran: $ g++ -DHAVE_CONFIG_H -I. -I../../../source/texk/web2c -I./.. -I/opt/tex/luatex/trunk/build/texk -I/opt/tex/luatex/trunk/source/texk -I/opt/tex/luatex/trunk/build/libs/zlib -I/opt/tex/luatex/trunk/build/libs/libpng -DPDF_PARSER_ONLY -I/opt/tex/luatex/trunk/build/libs/xpdf -I/opt/tex/luatex/trunk/build/libs/xpdf/goo -I/opt/tex/luatex/trunk/build/libs/xpdf/xpdf -I/opt/tex/luatex/trunk/build/libs/obsdcompat -I/opt/tex/luatex/trunk/source/libs/obsdcompat -I../../../source/texk/web2c/libmd5 -Iluatexdir -I../../../source/texk/web2c/luatexdir -I../../../source/texk/web2c/luatexdir/lua51 -DpdfTeX -g -O2 -Wall -Wextra -MT libluatex_a-pdftoepdf.o -MD -MP -MF .deps/libluatex_a-pdftoepdf.Tpo -c -o libluatex_a-pdftoepdf.o `test -f 'luatexdir/image/pdftoepdf.cc' || echo '../../../source/texk/web2c/'`luatexdir/image/pdftoepdf.cc And all I get are some harmless warnings about unused parameters.
2009/8/19 Mojca Miklavec
On Wed, Aug 19, 2009 at 10:53, Taco Hoekwater wrote:
I have just uploaded the archives for a new luatex release, 0.43.0.
Taco, thanks a lot. But the build on debian sarge (the one where I compile binaries for minimals) fails. Builds fine on freebsd-i386
-- Diego Depaoli
I have just built successfully 0.43.0 on lenny ppc. Is there any
special reason you build on sarge?
Piotr
2009/8/19 Mojca Miklavec
On Wed, Aug 19, 2009 at 10:53, Taco Hoekwater wrote:
I have just uploaded the archives for a new luatex release, 0.43.0.
Taco, thanks a lot. But the build on debian sarge (the one where I compile binaries for minimals) fails.
It's something like:
web2c/luatexdir/image/pdftoepdf.cc:1052: error: invalid conversion from 'void (*)(...)' to 'void (*)(void*, void*)' and some more errors before,
... but I need to figure out how to copy-paste text and most of all how to scroll a few lines back in terminal, or figure out where the log file is :)
(I'm using VMWare Fusion and have not much experience with it.)
Mojca
_______________________________________________ Mailing list: https://launchpad.net/~context Post to : context@lists.launchpad.net Unsubscribe : https://launchpad.net/~context More help : https://help.launchpad.net/ListHelp
On 2009-08-27, Piotr Kopszak wrote:
I have just built successfully 0.43.0 on lenny ppc. Is there any special reason you build on sarge?
Yes. I have tried building on a more recent machine and then quite some people using older systems were unable to execute the binary. For you it might not be such a big issue since there are probably not many linux ppc users wanting to install the latest context while insisting to keep working on an ancient system :) :) :) For linux on i386 architecture it's a bit different since the system is often installed by an admin and user has no choice. (The binaries built on recent system didn't work on the old contextgarden for example.) Mojca
That's right, no one complained till now. Thanks God I never had to
bother about glibc compatibility but it seems there are ways to build
backward compatible programs on fresher Debian systems. I don't know
if it helps but maybe
http://wiki.freegamedev.net/index.php/Portable_binaries
Piotr
2009/8/27 Mojca Miklavec
On 2009-08-27, Piotr Kopszak wrote:
I have just built successfully 0.43.0 on lenny ppc. Is there any special reason you build on sarge?
Yes. I have tried building on a more recent machine and then quite some people using older systems were unable to execute the binary. For you it might not be such a big issue since there are probably not many linux ppc users wanting to install the latest context while insisting to keep working on an ancient system :) :) :)
For linux on i386 architecture it's a bit different since the system is often installed by an admin and user has no choice. (The binaries built on recent system didn't work on the old contextgarden for example.)
Mojca
On Thu, Aug 27, 2009 at 13:22, Piotr Kopszak wrote:
That's right, no one complained till now. Thanks God I never had to bother about glibc compatibility but it seems there are ways to build backward compatible programs on fresher Debian systems. I don't know if it helps but maybe
I don't know how to intepret their text (I don't have too much time at the moment either), but quoting them: As an example, a binary compiled on a Debian Lenny system with glibc 2.7 won't run on a Debian Sarge system with glibc 2.3 because the older glibc version doesn't have all the features found and used when the binary was compiled on a newer system. A binary compiled on Debian Sarge will run on Debian Lenny, however, thanks to backwards compatibility. In practice, all this means is that you need to compile your application in a sufficiently old distribution. Examples of distributions that have been used successfully for making portable binaries include old glibc 2.2.5 based Red Hat Linux versions, Debian Sarge, and Debian Etch. Mojca
Right, but I'm afraid it may turn out a rather short-term solution in
the end. After all it's only (?) a question of linking against right
version of glibc.
P.
2009/8/27 Mojca Miklavec
On Thu, Aug 27, 2009 at 13:22, Piotr Kopszak wrote:
That's right, no one complained till now. Thanks God I never had to bother about glibc compatibility but it seems there are ways to build backward compatible programs on fresher Debian systems. I don't know if it helps but maybe
I don't know how to intepret their text (I don't have too much time at the moment either), but quoting them:
As an example, a binary compiled on a Debian Lenny system with glibc 2.7 won't run on a Debian Sarge system with glibc 2.3 because the older glibc version doesn't have all the features found and used when the binary was compiled on a newer system. A binary compiled on Debian Sarge will run on Debian Lenny, however, thanks to backwards compatibility.
In practice, all this means is that you need to compile your application in a sufficiently old distribution. Examples of distributions that have been used successfully for making portable binaries include old glibc 2.2.5 based Red Hat Linux versions, Debian Sarge, and Debian Etch.
Mojca
On Fri, Aug 28, 2009 at 08:14, Piotr Kopszak wrote:
Right, but I'm afraid it may turn out a rather short-term solution in the end. After all it's only (?) a question of linking against right version of glibc.
If you can figure it out how to do it, plase let me know. (I'm no linux guru.) About the short-termness: Apple offers switches for compiling for older platforms, but once I get my computer replaced, we'll have to compile the OSX binaries somewhere else or drop support for 2-3-year-old computers (Apple only offers backward-compatibility-compilation for one generation). Mojca
This is more a philosophical than a software engineering question,
that is whether it is really worth the effort, and for how long. Sarge
compatibility isn't going to be in Debian forever and more and more
bugs will get involved as time goes by. So I'm afraid in the end it's
a question of giving an advance warning to the users that Sarge
support will by dropped by some date rather than waste time which
could be used in a more productive way.
Piotr
2009/8/28 Mojca Miklavec
On Fri, Aug 28, 2009 at 08:14, Piotr Kopszak wrote:
Right, but I'm afraid it may turn out a rather short-term solution in the end. After all it's only (?) a question of linking against right version of glibc.
If you can figure it out how to do it, plase let me know. (I'm no linux guru.)
About the short-termness: Apple offers switches for compiling for older platforms, but once I get my computer replaced, we'll have to compile the OSX binaries somewhere else or drop support for 2-3-year-old computers (Apple only offers backward-compatibility-compilation for one generation).
Mojca
On Sat, Aug 29, 2009 at 13:24, Piotr Kopszak wrote:
This is more a philosophical than a software engineering question, that is whether it is really worth the effort, and for how long. Sarge compatibility isn't going to be in Debian forever and more and more bugs will get involved as time goes by. So I'm afraid in the end it's a question of giving an advance warning to the users that Sarge support will by dropped by some date rather than waste time which could be used in a more productive way.
Concerning Linux: it costs almost the same amount of work to support Sarge or Etch (ignoring a few bug reports that I send to Taco or Han every now and then, but if I would not send them, Karl would complain while compiling TeX Live anyway). Compiling on someone's working machine would mean that we would drop support for many more users than just for Sarge. If we compile in virtual machine it's almost irrelevant what distribution we have there. The "philosophical" question is much more relevant with Macs. In a few weeks I won't be able to provide binaries for platform that I have been using until just a few months ago. Mojca
Mojca Miklavec wrote:
The "philosophical" question is much more relevant with Macs. In a few weeks I won't be able to provide binaries for platform that I have been using until just a few months ago.
Actually, I could compile mac binaries now (I am not in a hurry to update to snow leopard at all, not for at least a year), but I really would rather not have to do so because it would be yet another task to perform before each release. Best wishes, Taco
On Sat, Aug 29, 2009 at 15:38, Taco Hoekwater wrote:
Mojca Miklavec wrote:
The "philosophical" question is much more relevant with Macs. In a few weeks I won't be able to provide binaries for platform that I have been using until just a few months ago.
Actually, I could compile mac binaries now (I am not in a hurry to update to snow leopard at all, not for at least a year), but I really would rather not have to do so because it would be yet another task to perform before each release.
Since when do you use mac? It can be made simpler: the one that will want the binaries may start compiling them :) (Not even XeTeX can be cross-compiled for Tiger on Leopard.) It makes no sense to put extra load on you. I just wanted to say that they have an extremely "nice" way to force users to buy new computers even if they don't really need a new one by simply not supporting any old machine any more. (One cannot install latest OS on old machines, programs stop working on old OS, so one is sooner or later forced to upgrade hardware even if processor/ram/hard drive still serves well.) Mojca (who wishes she was travelling with Luigi right now ... have a magnificent time at the conference)
Mojca Miklavec wrote:
On Sat, Aug 29, 2009 at 15:38, Taco Hoekwater wrote:
Mojca Miklavec wrote:
The "philosophical" question is much more relevant with Macs. In a few weeks I won't be able to provide binaries for platform that I have been using until just a few months ago. Actually, I could compile mac binaries now (I am not in a hurry to update to snow leopard at all, not for at least a year), but I really would rather not have to do so because it would be yet another task to perform before each release.
Since when do you use mac?
We bought a mac a few months ago, I have to do development on it for a client of Elvenkind. All C coding work, it doesn't have tex installed currently.
(who wishes she was travelling with Luigi right now ... have a magnificent time at the conference)
Thanks! We will think of you, and wish you good luck! Please graduate this year, so we won't have to miss you next year as well ... Best wishes, Taco
participants (5)
-
Arthur Reutenauer -
Diego Depaoli -
Mojca Miklavec -
Piotr Kopszak -
Taco Hoekwater