headers
Thorsten Ottosen | 2 Feb 15:19

changing lib prefix for static libraries on windows?

Hi all,

I found this old discussion:

http://boost.2283326.n4.nabble.com/quot-lib-quot-prefix-for-cross-compiled-library-in-cygwin-environment-td2685314.html

Basically, I would like to get rid of the "lib" prefix for static 
libraries on windows.

Can this be done now?

Thanks

-Thorsten
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Permalink | Reply | 0 comments |
headers
Igor Zavoychinskiy | 6 Feb 21:59
Picon

Building sgd library versions

Hello there,

Not sure if I'm writing to the correct place. Please feel free to correct me and point the right one.

Building boost 1.48 on Win7 for MSVC.2008 I discover a strange behavior: sgd versions are not get built if you request them explicitly. When I specify the following command:
b2.exe --stagedir=./ --build-dir=/tmp --toolset=msvc-9.0 threading=multi --link=static --runtime-link=static --with-thread

I expect to get the following libraries:
libboost_thread-vc90-mt-s-1_48.lib
libboost_thread-vc90-mt-sgd-1_48.lib

But in fact I get:
libboost_thread-vc90-mt-1_48.lib
libboost_thread-vc90-mt-gd-1_48.lib

Setting "--runtime-link=shared" results in the exactly the same set of output libraries which makes me believe this flag is just ignored.

I know the workaround and here is it:
b2.exe --stagedir=./ --build-dir=/tmp --toolset=msvc-9.0 --with-thread --build-type=complete

This way I get all the libraries built including the sgd versions. Though, I'd say this workaround is kind of expensive. Especially for continues build systems.

- Igor
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Permalink | Reply | 3 comments |
headers
Jürgen Hunold | 7 Feb 11:49
Picon

Re: Building sgd library versions

Hi Igor,

On Monday, 6. February 2012 21:59:19 Igor Zavoychinskiy wrote:
> Hello there,
> 
> Not sure if I'm writing to the correct place. Please feel free to correct me
> and point the right one.

Yes your are right-

> Building boost 1.48 on Win7 for MSVC.2008 I discover a strange behavior: sgd
> versions are not get built if you request them explicitly. When I specify
> the following command: b2.exe --stagedir=./ --build-dir=/tmp
> --toolset=msvc-9.0 threading=multi --link=static --runtime-link=static
> --with-thread
> 
> I expect to get the following libraries:
> libboost_thread-vc90-mt-s-1_48.lib
> libboost_thread-vc90-mt-sgd-1_48.lib
> 
> But in fact I get:
> libboost_thread-vc90-mt-1_48.lib
> libboost_thread-vc90-mt-gd-1_48.lib

This is expected. You have way too much "--" in your options ;-))

That should be 
"toolset=msvc-9.0 threading=multi link=static runtime-link=static"

for b2 options.

> Setting "--runtime-link=shared" results in the exactly the same set of
> output libraries which makes me believe this flag is just ignored.

Yes, because "runtime-link=shared" is the correct value.

> I know the workaround and here is it:
> b2.exe --stagedir=./ --build-dir=/tmp --toolset=msvc-9.0 --with-thread
> --build-type=complete

even her "--toolset" is wrong and just working because you have only Visual 
Studio 2008 installed.

> This way I get all the libraries built including the sgd versions. Though,
> I'd say this workaround is kind of expensive. Especially for continues
> build systems.

Definetely.

Hope this helps.

Yours, 

Jürgen
--

-- 
Dipl.-Math. Jürgen Hunold       | IVE mbH
Software-Entwickler             | Lützerodestraße 10 
Tel: +49 511 897668 33          | 30161 Hannover, Germany
Fax: +49 511 897668 29          | http://www.ivembh.de
juergen.hunold <at> ivembh.de        | 
                                | Geschäftsführer:
Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer               
Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke  

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Permalink | Reply | 2 comments |
headers
Igor Zavoychinskiy | 8 Feb 05:04
Picon

Re: Building sgd library versions

My bad, I mistaken "--" flags and these switches.

Thanks a lot!

2012/2/7 Jürgen Hunold <juergen.hunold <at> ivembh.de>
Hi Igor,

On Monday, 6. February 2012 21:59:19 Igor Zavoychinskiy wrote:
> Hello there,
>
> Not sure if I'm writing to the correct place. Please feel free to correct me
> and point the right one.

Yes your are right-

> Building boost 1.48 on Win7 for MSVC.2008 I discover a strange behavior: sgd
> versions are not get built if you request them explicitly. When I specify
> the following command: b2.exe --stagedir=./ --build-dir=/tmp
> --toolset=msvc-9.0 threading=multi --link=static --runtime-link=static
> --with-thread
>
> I expect to get the following libraries:
> libboost_thread-vc90-mt-s-1_48.lib
> libboost_thread-vc90-mt-sgd-1_48.lib
>
> But in fact I get:
> libboost_thread-vc90-mt-1_48.lib
> libboost_thread-vc90-mt-gd-1_48.lib

This is expected. You have way too much "--" in your options ;-))

That should be
"toolset=msvc-9.0 threading=multi link=static runtime-link=static"

for b2 options.

> Setting "--runtime-link=shared" results in the exactly the same set of
> output libraries which makes me believe this flag is just ignored.

Yes, because "runtime-link=shared" is the correct value.

> I know the workaround and here is it:
> b2.exe --stagedir=./ --build-dir=/tmp --toolset=msvc-9.0 --with-thread
> --build-type=complete

even her "--toolset" is wrong and just working because you have only Visual
Studio 2008 installed.

> This way I get all the libraries built including the sgd versions. Though,
> I'd say this workaround is kind of expensive. Especially for continues
> build systems.

Definetely.

Hope this helps.

Yours,

Jürgen
--
Dipl.-Math. Jürgen Hunold       | IVE mbH
Software-Entwickler             | Lützerodestraße 10
Tel: +49 511 897668 33          | 30161 Hannover, Germany
Fax: +49 511 897668 29          | http://www.ivembh.de
juergen.hunold <at> ivembh.de        |
                               | Geschäftsführer:
Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer
Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Permalink | Reply | 0 comments |
headers
Marc Dürner | 16 Feb 15:02

build engine crashes when GLOBing paths with forward slashes on windows

Hello,

I get a crash on windows when a path with forward slashes such as
/usr/include is passed to GLOB. I believe is has to do with the
implementation of ShortPathToLongPath in pathunix.c. There has been
special handling of short paths added recently for paths that only
contain the drive letter such as c:\. I can add special handling for
paths with forward slashes in a similar manner at the begin on
ShortPathToLongPath:

    if ( (short_path[0] == '\\') && (short_path[1] == '\0') )
    {
        string_push_back( out, '\\' );
        return;
    }

This fixes it, but seems only to hide a deeper problem.
ShortPathToLongPath() and path_write_key() call each other recursively
and we run into a situation in path_write_key() where a element was
added to the hashmap, but not completely initialized, A following
recursive call finds the element in the hashmap and tries to use the
elements uninitialized value.

regards,
Marc
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Permalink | Reply | 5 comments |
headers
Marc Dürner | 17 Feb 09:48

new EXEC builtin command

Hello boost builders,

I would like to suggest a new builtin rule named EXEC, or reimplement
for the SHELL builtin rule.

I have tried to use the current SHELL rule with mixed success. It
seems it does not work well under windows when paths have spaces and
the command needs to be qouted. The reason for this is a limited
implementation of popen on windows.

I have also observed that there is already code in jam that performs
execution of shell commands, the execcmd API. So it should be possible
to build the SHELL builtin rule on top of exec_cmd() and exec_wait().
Something like this:

static void exec_callback(void *closure, int status, timing_info*
time, const char* cmd, const char* output)
{
    exec_closure* ec = (closure*) closure;

    LIST* list = ec.result;

    /* move buffer into jam variables */
}

LIST *builtin_exec( FRAME * frame, int flags)
{
    LIST*              command = 0;
    OBJECT*        varname = 0;
    LIST*              shell = 0;
    exec_closure   ec;

    command = lol_get( frame->args, 0 );
    if( ! command )
        return L0;

    varname = object_new( "JAMSHELL" );
    shell = var_get( varname );
    object_free( varname );

    exec_cmd( object_str( command->value ), exec_callback, &ec, shell, 0, 0);
    exec_wait();

    /* ec.result is a LIST* */
    return ec.result;
}

Can we add such a builtin rule to bjam, or change the SHELL rule? It
works well on windows, linux and OS-X.

best regards,
Marc
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Permalink | Reply | 4 comments |
headers
Nogradi, Chris | 20 Feb 14:24
Favicon

Re: new EXEC builtin command

>From a user's perspective, what would be the difference between the SHELL and EXEC commands? What purpose
would there be to use one over the other on anything other than windows?

Chris

-----Original Message-----
From: boost-build-bounces <at> lists.boost.org [mailto:boost-build-bounces <at> lists.boost.org] On
Behalf Of Marc Dürner
Sent: Friday, February 17, 2012 2:49 AM
To: boost-build <at> lists.boost.org
Subject: [Boost-build] new EXEC builtin command

Hello boost builders,

I would like to suggest a new builtin rule named EXEC, or reimplement
for the SHELL builtin rule.

I have tried to use the current SHELL rule with mixed success. It
seems it does not work well under windows when paths have spaces and
the command needs to be qouted. The reason for this is a limited
implementation of popen on windows.

I have also observed that there is already code in jam that performs
execution of shell commands, the execcmd API. So it should be possible
to build the SHELL builtin rule on top of exec_cmd() and exec_wait().
Something like this:

static void exec_callback(void *closure, int status, timing_info*
time, const char* cmd, const char* output)
{
    exec_closure* ec = (closure*) closure;

    LIST* list = ec.result;

    /* move buffer into jam variables */
}

LIST *builtin_exec( FRAME * frame, int flags)
{
    LIST*              command = 0;
    OBJECT*        varname = 0;
    LIST*              shell = 0;
    exec_closure   ec;

    command = lol_get( frame->args, 0 );
    if( ! command )
        return L0;

    varname = object_new( "JAMSHELL" );
    shell = var_get( varname );
    object_free( varname );

    exec_cmd( object_str( command->value ), exec_callback, &ec, shell, 0, 0);
    exec_wait();

    /* ec.result is a LIST* */
    return ec.result;
}

Can we add such a builtin rule to bjam, or change the SHELL rule? It
works well on windows, linux and OS-X.

best regards,
Marc
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

This e-mail and any attachments may contain confidential material for the sole use of the intended
recipient. If you are not the intended recipient, please be aware that any disclosure, copying,
distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in
error, please contact the sender and delete all copies.

Thank you for your cooperation.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Permalink | Reply | 1 comment |
headers
Marc Dürner | 20 Feb 16:36

Re: new EXEC builtin command

Hi,

> >From a user's perspective, what would be the difference between the SHELL and EXEC commands? What
purpose would there be to use one over the other on anything other than windows?

I would be perfectly happy if the SHELL rule were changed internally
and built on top of the API provided by execcmd.h, so it works on all
platforms and duplicated code is removed.

I am not sure if the strip-eol option really does what the name
implies. Maybe it could be implemented such that all whitespace
characters (when isspace is true) are replaced with space, whitespace
following whitespace is removed and leading and trailing whitespace is
removed. That should be pretty portable, depending only on the isspace
function.

best regards,
Marc
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Permalink | Reply | 0 comments |
headers
Ray Lambert | 20 Feb 19:15

Re: Boost-build Digest, Vol 78, Issue 6

On 02/20/2012 12:00 PM, Marc wrote:
I am not sure if the strip-eol option really does what the name implies. Maybe it could be implemented such that all whitespace characters (when isspace is true) are replaced with space, whitespace following whitespace is removed and leading and trailing whitespace is removed. That should be pretty portable, depending only on the isspace function.
FYI: I added that option and it was designed specifically to avoid breaking any existing Jamfiles that might want embedded newlines in the result.  'strip-eol' only removes the final trailing newline and this works fine for the case I was addressing, which is capturing build options from a script (such as 'wx-config') to be inserted into a command line.  (This output usually consists of only a single line with a single trailing newline.)

Prior to this option, if you placed the output of something like 'wx-config' into <cxx-options> or <link-options> the final trailing newline was preserved and ended up causing bjam to generate an invalid command line (to the shell interpreter it appeared to be two separate command lines).  The only work-around was to pipe the result of 'wx-config' to something like 'tr' and tell it convert the newlines into a space; a bit hacky and not very portable.

I would recommend not changing how 'strip-eol' works as some folks may now rely on that behavior.  I have thought about adding another option to do what you suggest but I haven't really had the need for it.  It would trivial to do so, however.

~ray

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Permalink | Reply | 1 comment |
headers
Marc Dürner | 20 Feb 21:16

Re: Boost-build Digest, Vol 78, Issue 6

Hello,

> I would recommend not changing how 'strip-eol' works as some folks may now
> rely on that behavior.  I have thought about adding another option to do
> what you suggest but I haven't really had the need for it.  It would trivial
> to do so, however.

Adding a new option would be fine, but strip-eol could be enough for me too.
Though the existing strip-eol, should be fixed too, don't you think?
If output from the command is longer than 1024 bytes, whitespace might
be removed that is somewhere in the middle. I guess noone recognized
this, because output from pkg-config and such tools is usually not
that long...

How can we proceed?

regards,
Marc
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Permalink | Reply | 0 comments |

Gmane