[Fink-devel] Building/bootstrapping GHC on MacOS X

2003-03-06 Thread Jeremy Higgs
Hi everyone,

I'm trying to create a Fink package for GHC (Glasgow Haskell Compiler), 
which I require for my Computing course at Uni, and I was just 
wondering how to go about doing it... From what I've looked at, it 
actually requires a version of GHC or a haskell compiler already 
installed to actually compile GHC itself, which poses a bit of a 
problem.

There's a .dmg version of it available, put out by Wolfgang Thaller, 
but weighs in at 20Mb... which is pretty hefty. I spoke to him about 
it, and he said that bootstrapping GHC without a pre-existing 
installation is very time-consuming and complicated, and strongly 
suggested I grab a binary of another version and go from there... The 
only problems are, where do I get the binaries, and licensing issues.

Firstly, the only place I can think of that would have the binaries is 
the .dmg file, which is too big to download by itself. Alternatively, I 
could take the binary from the installed package and tar it up to be 
put onto the Fink servers.

However, this poses another problem... would this be disobeying the 
license that GHC is distributed under? It's located here: 
http://www.haskell.org/ghc/license.html

I'm not quite sure how to go about doing this... If it's legal, could I 
take the binary, repackage it into another archive and then create a 
package for that, in order to bootstrap  the GHC compiler itself? Of 
course, the binary could always be repackaged as a Fink package, but it 
wouldn't take advantage of the dependencies, and wouldn't be compiled 
on the computer itself.

Can anyone offer any suggestions?

Thanks a lot!



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: libpng3 (was Re: [Fink-devel] gtk+2-2.0.9-3 problems with xfree86-4.3.0-1)

2003-03-06 Thread David R. Morrison
Hi Martin.  Ben Reed and I discussed this a bit on IRC after I sent my
previous message.  He tells me that this libpng problem has been a
problem with libpng on Linux as well, that it doesn't behave as a
library is expected to do when you upgrade.  That gives me some real
hope that we won't have a repeat of this situation with XFree86 or
other upgrades.  So, no "Boom!", I hope!

  -- Dave


---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: libpng3 (was Re: [Fink-devel] gtk+2-2.0.9-3 problems with xfree86-4.3.0-1)

2003-03-06 Thread Martin Costabel
David R. Morrison wrote:
[]
As far as I can tell, you would be able to build foo with libpng headers
installed, just fine.  Everything will have libpng support compiled in, and
then at link time, you are linking against libpng3.dylib and all symbols are 
This part I don't understand: How would foo even know that it wants to 
link against libpng.3.dylib when it only sees libpng.2.dylib during 
build time? It links to -lpng, and /sw/lib/libpng.dylib is a symlink to 
libpng.2.dylib in your scenario.

successfully resolved, so everything is still fine.  It is only at
execution time that the mismatch is detected.
In the case of the gimp help browser, the scenario was different, I 
think, and not caused by any problem with Fink's build process, but by a 
principal problem of the shlibs policy:

gimp-1.2.3-10 (this was the version that showed the problem, the newer 
one eliminated it by depending on libpng3) build-depends on libpng and 
depends on libpng-shlibs. The gimp helpbrowser of this version therefore 
links with libpng.2.dylib. It also links with libgtkxmhtml.1.dylib from 
gnome-libs-shlibs. So far no problem, while the latter links with 
libpng.2.dylib, too. Next, gnome-libs-shlibs is upgraded to a new 
version that has a dependency on libpng3. libgtkxmhtml.1.dylib now links 
with libpng.3.dylib.

When helpbrowser is run, the dynamical linker loads libpng.2.dylib, then 
libgtkxmhtml.1.dylib and then libpng.3.dylib (confirmed by looking at 
DYLD_PRINT_LIBRARIES). At this point, the famous error message appears. 
Everything was compiled correctly, though.

Something similar might happen with the different xfree versions:

Binary foo is built while xfree-4.2 is installed. It links with -lXft 
which has the install-name /usr/X11R6/lib/libXft.1.dylib. foo also links 
with library libbar.1.dylib which is linked with -lXft, too. Now xfree 
is upgraded to 4.3.0 and package libbar is rebuilt. libbar.1.dylib now 
links with what libXft.dylib is symlinked to at this moment, namely 
libXft.2.1.dylib with install-name /usr/X11R6/lib/libXft.2.dylib.

At runtime of foo, dyld loads first libXft.1.dylib (yes, this still 
exists in xfree-4.3.0 for compatibility reasons!), then libbar.1.dylib, 
then libXft.2.dylib. Boom! (Or maybe not?)

--
Martin








---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: libpng3 (was Re: [Fink-devel] gtk+2-2.0.9-3 problems with xfree86-4.3.0-1)

2003-03-06 Thread Benjamin Reed
David R. Morrison wrote:

Well, I hope not.  I still don't fully understand what is happening with the
libpng/libpng3 business, but I strongly suspect the following scenario.  You
ask fink to install "foo" and it also requires "bar" so fink is going to
install both at once.  Let's say foo depends on libpng3 and bar depends on
libpng.  What does fink do?
  1) First loads libpng3 because thats what foo wants
  2) Next loads libpng because thats what bar wants
  3) Successfully compiles bar, linked to libpng.
  4) Manages to compile foo, with libpng still installed, because the
dependecies are not checked a second time just prior to building.
Yup, I'm pretty sure that's how it's triggered.  That also supports the 
fact that a rebuild of the offending package usually puts it right as well.



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


libpng3 (was Re: [Fink-devel] gtk+2-2.0.9-3 problems with xfree86-4.3.0-1)

2003-03-06 Thread David R. Morrison

On Mar 6,2003 21:45:17 +0100, Martin Costabel <[EMAIL PROTECTED]> wrote :

>But I suspect that as soon as you start compiling things under 4.3.0, 
>there will be conflicts of the libpng/libpng3 variety (one version of 
>library loaded directly, another one indirectly -> crash)

Well, I hope not.  I still don't fully understand what is happening with the
libpng/libpng3 business, but I strongly suspect the following scenario.  You
ask fink to install "foo" and it also requires "bar" so fink is going to
install both at once.  Let's say foo depends on libpng3 and bar depends on
libpng.  What does fink do?
  1) First loads libpng3 because thats what foo wants
  2) Next loads libpng because thats what bar wants
  3) Successfully compiles bar, linked to libpng.
  4) Manages to compile foo, with libpng still installed, because the
dependecies are not checked a second time just prior to building.

As far as I can tell, you would be able to build foo with libpng headers
installed, just fine.  Everything will have libpng support compiled in, and
then at link time, you are linking against libpng3.dylib and all symbols are 
successfully resolved, so everything is still fine.  It is only at
execution time that the mismatch is detected.

Does this scenario make sense to anyone else?  Has anybody seen a symptom
which is not consistent with this?

  -- Dave





---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] gtk+2-2.0.9-3 problems with xfree86-4.3.0-1

2003-03-06 Thread Martin Costabel
David R. Morrison wrote:
[]
Martin, I'd like to understand this situation better.  Are there specific
libraries which have been updated for 4.3?  Were the updates done in a
properly versioned manner?  If so, then packages which are compiled under
4.3 will link to the new versions, and packages compiled under 4.2 will
link to the old versions.  So long as we keep the different versions in
separate fink packages, a smooth transition should be possible.
Here is, for example, a list of libraries in 4.3.0 that aren't in 4.2.1

/usr/X11R6_4.3.0/lib/libOSMesa.4.0.dylib
/usr/X11R6_4.3.0/lib/libXcursor.1.0.dylib
/usr/X11R6_4.3.0/lib/libXft.2.0.dylib
/usr/X11R6_4.3.0/lib/libXft.2.1.dylib
/usr/X11R6_4.3.0/lib/libXrandr.2.0.dylib
/usr/X11R6_4.3.0/lib/libXrender.1.2.dylib
/usr/X11R6_4.3.0/lib/libXv.1.0.dylib
/usr/X11R6_4.3.0/lib/libexpat.1.0.dylib
/usr/X11R6_4.3.0/lib/libfontconfig.1.0.dylib
/usr/X11R6_4.3.0/lib/libfreetype.6.3.dylib
Some of them are higher versions (Xft, Xrandr, Xrender, freetype), and 
the others must correspond to new APIs which I don't know anything about.

The updated ones are done in a proper manner, so that compatibility is 
guaranteed in one direction, at least.
But I suspect that as soon as you start compiling things under 4.3.0, 
there will be conflicts of the libpng/libpng3 variety (one version of 
library loaded directly, another one indirectly -> crash)
Then, as has been detected from the case of pango, some headers have 
disappeared in 4.3.0. Others are new in 4.3.0.



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] gtk+2-2.0.9-3 problems with xfree86-4.3.0-1

2003-03-06 Thread David R. Morrison
Martin Costabel <[EMAIL PROTECTED]> wrote:

> This was already on the beginners and users lists, and it is mentioned 
> in the pango description.
> 
> Recompile doesn't work, the packages need to be ported to xfree-4.3.0.
> 
> I said it some time ago, but it was considered too pessimistic at that 
> time:
> 
> The upgrade from xfree-4.2 to 4.3 has some unpleasant similarities to 
> the Jaguar upgrade.
> 
> - There are packages that won't compile under 4.3
> - Packages and libraries compiled under 4.3 will not work under 4.2, in 
> general, so you can't go back. "In general" may concern only very few 
> packages if we are lucky.
> - The threaded vs non-threaded issue has not been solved. Threaded is 
> now the default, so on the subject of Matlab, the ball is in 
> Apple's/Matlab's field now, but the fact remains that Matlab doesn't 
> work with 4.3.0.
> 
> IMHO there should be some big red warnings somewhere.
> 

Martin, I'd like to understand this situation better.  Are there specific
libraries which have been updated for 4.3?  Were the updates done in a
properly versioned manner?  If so, then packages which are compiled under
4.3 will link to the new versions, and packages compiled under 4.2 will
link to the old versions.  So long as we keep the different versions in
separate fink packages, a smooth transition should be possible.

(I'm not sure that we've done this yet, but it should be possible to
repackage things with this in mind.)

I don't have a good answer for the threaded issue, though.  Is Matlab the
only affected package?

The Jaguar upgrade was much worse, because the change of compiler produced
changes which were not tracked by library versioning.

  -- Dave





---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] gtk+2-2.0.9-3 problems with xfree86-4.3.0-1

2003-03-06 Thread Martin Costabel
On jeudi, mars 6, 2003, at 14:54 Europe/Paris, thomas kotzian wrote:
[]
configure: error: pangoxft Pango backend found, but Xft not found
### execution of ./configure failed, exit code 1
Failed: compiling gtk+2-2.0.9-3 failed
does pango need a recompile - which other packages too??
This was already on the beginners and users lists, and it is mentioned 
in the pango description.

Recompile doesn't work, the packages need to be ported to xfree-4.3.0.

I said it some time ago, but it was considered too pessimistic at that 
time:

The upgrade from xfree-4.2 to 4.3 has some unpleasant similarities to 
the Jaguar upgrade.

- There are packages that won't compile under 4.3
- Packages and libraries compiled under 4.3 will not work under 4.2, in 
general, so you can't go back. "In general" may concern only very few 
packages if we are lucky.
- The threaded vs non-threaded issue has not been solved. Threaded is 
now the default, so on the subject of Matlab, the ball is in 
Apple's/Matlab's field now, but the fact remains that Matlab doesn't 
work with 4.3.0.

IMHO there should be some big red warnings somewhere.

--
Martin




---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] gtk+2-2.0.9-3 problems with xfree86-4.3.0-1

2003-03-06 Thread Max Horn
Am Donnerstag, 06.03.03 um 14:54 Uhr schrieb thomas kotzian:

I have upgraded xfree86 to 4.3.0 with the xfree86-upgrade script. 
gtk+2 cannot compile and exits with:

checking for IceConnectionNumber in -lICE... yes
checking for XRenderFindFormat in -lXrender... yes
checking for XftFontOpen in -lXft... yes
checking X11/Xft/XftFreetype.h usability... no
checking X11/Xft/XftFreetype.h presence... no
checking for X11/Xft/XftFreetype.h... no
configure: error: pangoxft Pango backend found, but Xft not found
### execution of ./configure failed, exit code 1
Failed: compiling gtk+2-2.0.9-3 failed
does pango need a recompile - which other packages too??

AFAIK GTK+ 2.0.x doesn't work with XFree86 4.3, while 2.1 doesn't work 
with XFree86 4.2, or something like this. Masanori sent a post on this 
subject some time ago (which was never addressed, hence I was somewhat 
upset when XFree86 4.3 was put into unstable w/o taking care of this... 
but that's past now )

Maybe for the time being, we should add a Conflicts to GTK+2 that 
prevents it from being used with XFree86.

Max



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


[Fink-devel] gtk+2-2.0.9-3 problems with xfree86-4.3.0-1

2003-03-06 Thread thomas kotzian
I have upgraded xfree86 to 4.3.0 with the xfree86-upgrade script. gtk+2 
cannot compile and exits with:

checking for IceConnectionNumber in -lICE... yes
checking for XRenderFindFormat in -lXrender... yes
checking for XftFontOpen in -lXft... yes
checking X11/Xft/XftFreetype.h usability... no
checking X11/Xft/XftFreetype.h presence... no
checking for X11/Xft/XftFreetype.h... no
configure: error: pangoxft Pango backend found, but Xft not found
### execution of ./configure failed, exit code 1
Failed: compiling gtk+2-2.0.9-3 failed
does pango need a recompile - which other packages too??

thanks, thomas

--
thomas kotzian, [EMAIL PROTECTED]


---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] system-emacs?

2003-03-06 Thread Max Horn
Am Donnerstag, 06.03.03 um 04:14 Uhr schrieb Ben Hines:

On Wednesday, March 5, 2003, at 10:42  AM, David R. Morrison wrote:

If you want to use the system emacs, don't make it depend on the 
emacsen-common,
and make sure that emacs is called as /usr/bin/emacs.

or just let it use either one, unless it depends on the features of a 
particular version.

Hm, so where and how does he install the elisp files so that both 
emacsen can find it (the system one and the fink one) ? (I did never 
bother to instlal extensions to emacs so I don't know, this is not 
meant as flame bait but a serious question :-)

Max



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Fwd: [Fink-devel] Epoch

2003-03-06 Thread Max Horn


Anfang der weitergeleiteten E-Mail:

Von: Max Horn <[EMAIL PROTECTED]>
Datum: Do, 6. Mär 2003  13:14:15 Europe/Berlin
An: Ben Hines <[EMAIL PROTECTED]>
Betreff: Re: [Fink-devel] Epoch
Am Donnerstag, 06.03.03 um 04:12 Uhr schrieb Ben Hines:

On Wednesday, March 5, 2003, at 10:14  AM, Max Horn wrote:

At 12:29 Uhr -0500 05.03.2003, Benjamin Reed wrote:
Max Horn wrote:
But my motivation to agree to this is most definitely not due to 
what the debian policy says. We are not debian! Sure we can look 
at how they do things, and if we like it, do it the same way, but 
I feel in no way bound to this. In particular, they ask to avoid 
epochs as much as possible, with no reason given (that I could 
find, please quote to prove me differently, would be much 
appreciated). The only reason given was by Kyle and others, which 
is that Epochs have to stay around the whole life time of a 
package... now, how is that a problem? I honestly don't see how it 
is a problem, so any explanation would be much appreciated, too.
The reason I see it as a problem is just as a usability issue. 
Packagers will know what version 1:3.0.2-4 means, but regular users 
won't.
Usually there should be no need to display the epoch to end users at 
all...

Bute no need to argue much about this, if we all can agree to the 
"0" trick you proposed


.. um, Max, the "0" trick is completely consistent with my views and 
debian's policy.  How does debian's policy and your views differ 
again, explain in slow words so i can understand. :)

Sure I am always willing to help the slow witted. 8-)

I ... am ... not ... agreeing ... with ... the ... quote: "It is not 
intended to cope with version numbers containing strings of letters 
which the package management system cannot interpret". I ... am ... 
only ... willing ... to ... agree ... to ... this ... "0" ... approach 
... as ... a ... compromise ... because ... everybody ... seems ... to 
... want ... to ... avoid ... epochs ... for ... this ... purpose. I 
... do ... not ... agree ... with ... the ... reasoning ... though. 
But ... I ... do  not ... care ... too ... strongly ... about ... 
it.



Max



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


[Fink-devel] Fioricet, Soma, Buspar, Prozac, and more Prescribed Online and Shipped to Your Door

2003-03-06 Thread Bradly Cho

 Order Confirmation. Your order
  should be shipped by January, via FedEx. Your Federal Express tracking number
  is.
   Thank you for registering. 
  Wholesale Prescription Medications!
  OUR DOCTORS WILL WRITE YOU A PRESCRIPTION FOR FREE
  
  Buy Your Prescription Meds Online
  
  Lowest Prices – No Prior Prescription Required
  Click
  Here
Upon Approval, Our US Licensed
Doctors will Prescribe Your Medication For Free
And Have the Medication Shipped Overnight To Your Door.
  We assure you the absolute
best value on the Internet.
Click
Here 
  Medications for: Weight
Loss, Pain Relief, Muscle Pain Relief, Women's Health, Men's Health, 
Impotence, Allergy Relief, Heartburn Relief, Migraine Relief
  Medications like: Phentermine,
Adipex, Soma, Fioricet, Ultram, Celebrex,
Viagra, Valtrex, Zyban, and many, many more.
  Click 
Here

remove
  me from your list


jeyo m pl
 y ylvhducv efad ogtgbjjppgw tmzp fubd e zpznkyuwonpmc
jf
gfeyydruortxd

vqgouz
fw