Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[slainer68]

Everytime I want to update aMule CVS with a new version, I cannot throw it to the trash and empty it, I always get : "libcurl.2.dylib is in used" message.

It would be great to fully free all the RAM when quitting aMule...

Thanks.

[drbee]

same problem here

[m2kio]

i assume you do not link wxMac statically.
why exactly the lib remains 'in use' i don't know. but using a statically linked wxMac will hopefully fix it.

to recompile wxMac with static linking you need option --disable-shared to ../configure in wxMac.
see: howto.txt

i hope there is no problem with the libcurl itself.

... m2kio !

[ken]

Actually, m2kio, this is a problem with the binary builds we distribute.  I believe that for those, wxMac is built and linked as a static library, but libcurl is linked dynamically and a copy is distributed inside the aMule.app.

The problem then results from the fact that once a dynamic library is loaded, the OS doesn't unload it even after the program using it has quit.  So, the library is "in use" and the Trash can't be emptied.

I don't know exactly why this decision was made.  My version of Panther (10.3.8 ) includes libcurl 7.10.2.  In fact, since I don't have an alternative libcurl installed, when I run the script being used to make the binaries it ends up just copying that OS-supplied library into the binary.  I presume that at some point somebody determined (or assumed?) that this library would not be available on all Panther installs.  I don't know if that's correct.

Hmm.  I poked around a bit.  I listed the contents of the package receipts of system component installations (/Library/Receipts) and found that curl is only mentioned in the base packages representing the original OS install.  It isn't mentioned in any updates.  So, it seems that we can rely on a libcurl sufficient for aMule's purposes on any Panther install.  Since our binaries currently only support Panther and later (not Jaguar), we should be able to remove this from the binaries.  This will solve the current problem, make the binary distribution slightly smaller, maybe reduce redundant memory use, and avoid conflicts with the system library if Apple upgrades it in future OS versions.  Very good, all around.  

[m2kio]

hi ken,
thanks for that research.
actually i found that i also cannot delete the official "binary build we distribute" after having used it. libcurl is in use. X(
but i can delete the builds which i make for myself without problem. so i assume that building amule as in my 'howto' will just work. that's good news.

a thing which puzzles me anyway is the binaries' size. the 'official' builds by lionell77 are ~140MB, my builds are ~60MB, though i enable all the debugging stuff, afaik. what the heck do i omit here?

... m2kio !

[ken]

Originally posted by m2kio
a thing which puzzles me anyway is the binaries' size. the 'official' builds by lionell77 are ~140MB, my builds are ~60MB, though i enable all the debugging stuff, afaik. what the heck do i omit here?

I don't know.  There are several possible differences.  You'll have to check with lionel77 to determine his exact configure flags.  For wxMac, I use

configure --disable-shared --enable-debug --enable-debug_gdb --enable-unicode

For aMule, I use

configure --enable-debug --disable-systray --disable-gtk

I suspect that lionel77 is using something similar.  My aMule.app is ~133MB.  I think lionel77's binaries include amuleweb, which mine doesn't.

[lionel77]

i'm using basically the same flags that ken is using (exacly the same for wx and just a few additional ones for amule, like webserver etc.).

so the difference between your builts, m2kio, and mine is probably that you enable debug for amule but not for wx and i enable it for both.
my binaries do contain the webserver (inside the package under Contents/MacOS), so that adds an additional ~12mb.

anyway, ken updated the packager script i'm using to not bundle libcurl automatically anymore, so all new binaries (including the one i posted today) won't exhibit the behavior described in the fist posting in this thread...

[m2kio]

hi lionell77,
yes, it's the debugging stuff for the wx lib. i already found this out but was too lame to post...  :O
and i'll leave mine this way.

m2kio !