Hi, I'm trying to generate an ebuild for mldonkey-3.1.3 from version 3.1.0 in a "x86_64" machine.

To manually compile de project I have to export LDFLAGS="-png15" before running ./configure



the problem is that I don't know how to export it inside the ebuild, I've tried with "append-ldflags -lpng15" in different places but, that doesn't seem to work.



Does anybody have an idea?

Regards.
--
Alexandre Paz Mena

On 09/14/2012 04:58 AM, Alexandre Paz Mena wrote:
> Hi, I'm trying to generate an ebuild for mldonkey-3.1.3 from version
> 3.1.0 in a "x86_64" machine.
>
> To manually compile de project I have to export LDFLAGS="-png15" before
> running ./configure
>
> the problem is that I don't know how to export it inside the ebuild,
> I've tried with "append-ldflags -lpng15" in different places but, that
> doesn't seem to work.
>
> Does anybody have an idea?

The *real* way is to tell upstream to fix their build system. But this
works too:


--- /usr/portage/net-p2p/mldonkey/mldonkey-3.1.0.ebuild 2012-02-24
16:01:22.000000000 -0500
+++ ./mldonkey-3.1.3.ebuild 2012-09-14 09:47:39.613742734 -0400
@@ -92,7 +92,13 @@

src_compile() {
export OCAMLRUNPARAM="l=256M"
- emake || die "emake failed"
+
+ local my_extra_libs
+ if use gd; then
+ my_extra_libs="-lpng15"
+ fi
+
+ emake LIBS="${my_extra_libs}" || die "emake failed"

if ! use guionly; then
emake utils || die "emake utils failed"

--- /usr/portage/net-p2p/mldonkey/mldonkey-3.1.0.ebuild 2012-02-24

16:01:22.000000000 -0500

+++ ./mldonkey-3.1.3.ebuild * * 2012-09-14 09:47:39.613742734 -0400

@@ -92,7 +92,13 @@



*src_compile() {

* * * * export OCAMLRUNPARAM="l=256M"

- * * * emake || die "emake failed"

+

+ * * * local my_extra_libs

+ * * * if use gd; then

+ * * * * * * * my_extra_libs="-lpng15"

+ * * * fi

+

+ * * * emake LIBS="${my_extra_libs}" || die "emake failed"



* * * * if ! use guionly; then

* * * * * * * * emake utils || die "emake utils failed"




Thanks, I'll post a bug to upstream.



Meanwhile, instead of adding libs, I worked adding them to econf.

But a new problem has appeared, mldonkey-3.1.3 seems to not have a init.d script. I thought that was the ebuild work, but both ebuilds are almost the same and now I'm looking through the tarballs to see any differences related to that.



Regards.
--
Alexandre Paz Mena

On 09/15/2012 11:59 AM, Alexandre Paz Mena wrote:
>
> Thanks, I'll post a bug to upstream.
>
> Meanwhile, instead of adding libs, I worked adding them to econf.
>
> But a new problem has appeared, mldonkey-3.1.3 seems to not have a
> init.d script. I thought that was the ebuild work, but both ebuilds are
> almost the same and now I'm looking through the tarballs to see any
> differences related to that.

The init scripts are usually stored in the package's "files" directory.
You should see the mldonkey one here:

$ ls /usr/portage/net-p2p/mldonkey/files/
total 12K
-rw-r--r-- 1 root root 1.6K 2008-06-30 12:12 2.9.5-execstacks.patch
-rw-r--r-- 1 root root 887 2007-01-24 12:40 mldonkey.confd-2.8
-rw-r--r-- 1 root root 3.1K 2011-10-23 14:22 mldonkey.initd

The ebuild in portage (tries to) install this:

...
newinitd "${FILESDIR}/mldonkey.initd" mldonkey


A guess: you copied the ebuilds to an overlay, but didn't copy the
"files" directory. Normally you'd get an error as a result, but there's
a bug (lots of them, actually) in the ebuild. In earlier EAPIs, the
dofoo/newfoo functions could fail but would not do so automatically. The
usual way to handle this is with e.g.

newinitd x y || die "newinitd didn't work"

The ebuild doesn't do this, so it happily continues after failing to
install the init script.

Ok, thank you very much!

Apart from that, I should add those files to the dependencies, right?

On Sun, Sep 16, 2012 at 4:33 AM, Michael Orlitzky <michael@orlitzky.com> wrote:


On 09/15/2012 11:59 AM, Alexandre Paz Mena wrote:

>

> Thanks, I'll post a bug to upstream.

>

> Meanwhile, instead of adding libs, I worked adding them to econf.

>

> But a new problem has appeared, mldonkey-3.1.3 seems to not have a

> init.d script. I thought that was the ebuild work, but both ebuilds are

> almost the same and now I'm looking through the tarballs to see any

> differences related to that.



The init scripts are usually stored in the package's "files" directory.

You should see the mldonkey one here:



* $ ls /usr/portage/net-p2p/mldonkey/files/

* total 12K

* -rw-r--r-- 1 root root 1.6K 2008-06-30 12:12 2.9.5-execstacks.patch

* -rw-r--r-- 1 root root *887 2007-01-24 12:40 mldonkey.confd-2.8

* -rw-r--r-- 1 root root 3.1K 2011-10-23 14:22 mldonkey.initd



The ebuild in portage (tries to) install this:



* ...

* newinitd "${FILESDIR}/mldonkey.initd" mldonkey





A guess: you copied the ebuilds to an overlay, but didn't copy the

"files" directory. Normally you'd get an error as a result, but there's

a bug (lots of them, actually) in the ebuild. In earlier EAPIs, the

dofoo/newfoo functions could fail but would not do so automatically. The

usual way to handle this is with e.g.



* newinitd x y || die "newinitd didn't work"



The ebuild doesn't do this, so it happily continues after failing to

install the init script.





--
Alexandre Paz Mena

On 09/16/12 04:20, Alexandre Paz Mena wrote:
> Ok, thank you very much!
>
> Apart from that, I should add those files to the dependencies, right?

Nope, all you should have to do is copy the net-p2p/mldonkey/files
directory into the corresponding directory in your overlay.

The "2.9.5-execstacks.patch" file might not be needed for the 3.1.x
you're building, but it won't hurt anything to leave it there.