(no subject)

[Lea Holloway]

c;ia_lis s_o:ftab's
place under tongue 10 min before action for 24 hourly results.
more info here

no thanks




___
http://lists.gnu.org/mailman/listinfo/libtool

(no subject)

[Gavin Myers]

c;ia_lis s_o:ftab's
place under tongue 10 min before action for 24 hourly results.
more info here

no thanks




___
http://lists.gnu.org/mailman/listinfo/libtool

partial linking

[Andreas Fenkart]

Hi all

Sorry for sending the mail a second time, but I forgot the subject in the
first one.

I have a question regarding partial linking. I found a thread earlier on
this list, namely here.

http://lists.gnu.org/archive/html/libtool/2004-12/msg00249.html

Unfortunately there was no answer on doing partial linking the right way.
The answer given suggests adding dummy functions and reference them from
elsewhere in the code. That's exactly what I try to avoid.

This is what I do
$(LIBTOOL) --mode=link g++ -o $(OBJDIR)/intermediate.lo/\
 $(OBJS:.o=.lo)
$(LIBTOOL) --mode=link g++ -o $(LIBDIR)/$(LA_LIBFILENAME) \
 -rpath $(INSTALLLIB_DIR) \
 $(OBJDIR)/intermediate.lo

Unfortunately this fails, because the intermediate.lo is not a textfile
describing where the PIC object is found, but the PIC object itself. No
object is placed into the .libs directory, which libtool usually does when
building *.lo files.

I read the code(libtool-1.5.10) and I'm willing to add the necessary bits to
create a proper .lo file. (Basically just copy-paste from the compile-case).
I'm just asking myself if the current behavior is on purpose, or an
oversight.
Anybody out here who can tell me how partial linking was thought to be used
in the first place.

kind regards,
Andy

-- 
+++ Sparen Sie mit GMX DSL +++ http://www.gmx.net/de/go/dsl
AKTION für Wechsler: DSL-Tarife ab 3,99 EUR/Monat + Startguthaben


___
http://lists.gnu.org/mailman/listinfo/libtool

(no subject)

[Andreas Fenkart]

Hi all

I have a question regarding partial linking. I found a thread earlier on
this list, namely here.

http://lists.gnu.org/archive/html/libtool/2004-12/msg00249.html

Unfortunately there was no answer on doing partial linking the right way.
The answer given suggests adding dummy functions and reference them from
elsewhere in the code. That's exactly what I try to avoid.

This is what I do
$(LIBTOOL) --mode=link g++ -o $(OBJDIR)/intermediate.lo/\
 $(OBJS:.o=.lo)
$(LIBTOOL) --mode=link g++ -o $(LIBDIR)/$(LA_LIBFILENAME) \
 -rpath $(INSTALLLIB_DIR) \
 $(OBJDIR)/intermediate.lo 

Unfortunately this fails, because the intermediate.lo is not a textfile
describing where the PIC object is found, but the PIC object itself. No
object is placed into the .libs directory, which libtool usually does when
building *.lo files.

I read the code(libtool-1.5.10) and I'm willing to add the necessary bits to
create a proper .lo file. (Basically just copy-paste from the compile-case).
I'm just asking myself if the current behavior is on purpose, or an
oversight. 
Anybody out here who can tell me how partial linking was thought to be used
in the first place. 

kind regards,
Andy


-- 
+++ Sparen Sie mit GMX DSL +++ http://www.gmx.net/de/go/dsl
AKTION für Wechsler: DSL-Tarife ab 3,99 EUR/Monat + Startguthaben


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Understanding -static

[Peter O'Gorman]

Akim Demaille wrote:
Right.  But linking statically a dynamic library doesn't sound
absurd to me (but I may be naive here).  At least, it works fine
on GNU/Linux.
Perhaps libtool should complain that -static was specified and no  static
library was available in this case? How on earth does linux manage  this?

What is the problem actually?
Part of the problem is probably my total failure to understand why/how this 
works on GNU/Linux. Does libtool generate a wrapper script for the 
executable there? Or does it include the path to the libraries build time 
location in the rpath?

Since darwin does not yet have rpath the location that the shared library 
will be at after it is installed is stored in the executable (and other 
shared libraries), which means that a wrapper script would be required in 
this circumstance. I suppose the fact that the wrapper script is not 
generated is a bug :( It should be possible for libtool to figure out if it 
has both the -static flag and a shared library on the link line for and 
generate a wrapper script if that is the case, I'll need to look into it.


When I use gcc directly, I have a weird failure.
sulaco% g++ -o hw main.o -static ./.libs/libhw.dylib
ld: can't locate file for: -lcrt0.o
There is nothing like crt0 on my machine.
Apple does not support complete static linking, the best explanation I could 
find as to why is here: 
, Jim 
Magee, the author of that mail is, I believe, a lead developer in the kernel 
group at Apple.

Peter
--
Peter O'Gorman - http://www.pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool

New product! Cialis soft tabs.

[Rob Ott]

Hi!

We have a new product that we offer to you, C_I_A_L_I_S soft tabs,

Cialis Soft Tabs is the new impotence treatment drug that everyone is talking 
about.Soft Tabs acts up to 36 hours, compare this to only two or three hours
of Viagra action! The active ingredient is Tadalafil, same as in brand Cialis.

Simply disolve half a pill under your tongue, 10 min before sex, for the best 
erections you've ever had!

Soft Tabs also have less sidebacks (you can drive or mix alcohol drinks with 
them).

You can get it at: http://demand4rx.com/soft/





No thanks: http://demand4rx.com/rr.php



___
http://lists.gnu.org/mailman/listinfo/libtool